Live container migration has always had an awkward answer in the Linux container world: CRIU. It checkpoints process memory, it restores it elsewhere, and whether it works at all depends on what is running inside the container. Incus 7.4, announced on August 28, 2026 and picked up more widely on August 30, takes a different route for containers on local ZFS or Btrfs storage. It does not move memory. It ships incremental filesystem snapshots to the destination while the container keeps running, and only stops it for the final sync. That is a narrower promise than true live migration, and for most workloads it is a far more reliable one.
The short answer
Incus 7.4 adds near live migration for containers on local ZFS or Btrfs storage. Instead of checkpointing process memory with CRIU, it sends a series of incremental filesystem snapshots to the destination while the container keeps running, and stops the container only for the last delta. It is exposed through incus move with the refresh option and through a refresh-migrate mode for cluster evacuations. Other storage drivers are not supported because they have no efficient snapshot transfer path. The release also adds UEFI database management for virtual machines, DNS NOTIFY on network zones, burst input and output limits, a librbd backend for Ceph RBD, and raises the minimum Open vSwitch and OVN versions.
Anyone who has tried to evacuate a container host under time pressure knows the shape of the problem. The root filesystem is tens of gigabytes, the copy takes minutes, and the container is stopped for all of them. CRIU was supposed to fix that, and sometimes it does, but its success rate is a function of what the workload happens to be doing, which is a terrible property in a maintenance window.
The trick is that it does not move memory at all
Incus 7.4 sidesteps the whole question. The container's filesystem is transferred to the target server through a series of incremental snapshots while the container keeps running. Each pass is smaller than the last, because each one only carries what changed since the previous snapshot. When the deltas are small enough, Incus stops the container, sends one final delta and starts it on the destination.
The container does stop. Connections drop, processes restart, and anything holding in memory state without persisting it is gone. This is not a transparent move and the project does not pretend otherwise. What changes is the length of the stop: instead of scaling with the size of the root filesystem, it scales with how much churn happened during the last snapshot interval. For a web tier, a worker pool or anything that already assumes it can be restarted, that is the difference between a maintenance window and a blip.
You reach it through the interface you already use, incus move with the refresh option, and there is a refresh-migrate mode for cluster evacuations. That second one is the real target. Draining a node before a kernel upgrade is the case where a long freeze on every workload is least acceptable and most common.
Why ZFS and Btrfs, and nobody else
Both filesystems can express the difference between two snapshots as a stream, cheaply, without reading the whole dataset. That is the entire mechanism. The developers state plainly that other storage drivers lack an efficient snapshot transfer mechanism suitable for this kind of migration, so there is no fallback: if your containers sit on directory backed, LVM or Ceph storage, you get the old stop, copy, start behaviour.
It is a useful reminder when choosing a storage backend. The comparison is usually framed around snapshots, compression and checksums, and those matter, but the feature set that a storage driver enables above it is the part you feel three years later. If you are still weighing platforms, our Proxmox, ESXi and Hyper-V comparison covers the same tradeoff from the hypervisor side, and the OpenZFS 2.4.4 notes cover what has been changing underneath.
The rest of the release, in operator order
Networking. Restricted projects can now reach selected networks belonging to the default project through restricted.networks.access, which removes a common reason to give a project more privilege than it needs. Network zones gained DNS NOTIFY, so a secondary server refreshes as soon as a record changes rather than waiting out its refresh timer. There are new IPv6 router advertisement controls through ipv6.ra and additional OVN multicast options.
Throughput controls. Virtual machine disks and network devices gained burst read and write limits, so a rate cap no longer has to punish short spikes to hold a long term average. Bridged, point to point and routed NICs gained a configurable queue.discipline, which is the knob you want when a single noisy instance is filling a queue and hurting everything sharing the bridge.
Storage. Ceph RBD gained an option to use the librbd userspace library rather than the kernel client, which lines up feature support with what the cluster actually offers. Shared cluster storage pools can now be recovered through incus admin recover, closing a gap that previously turned a recoverable pool into a rebuild.
Virtual machine boot. There is a new incus low-level secureboot command family for listing, adding, removing, importing and exporting UEFI database entries, plus configuration keys that populate those databases when an instance is created. Separately, incus start gained an override option to pick a boot entry from NVRAM once, without permanently changing the order. Anyone who has tried to boot a rescue image inside a virtual machine with a stubborn boot order will recognise the value.
Client. Remotes can now carry their own client certificate through per remote certificate and key options, instead of every remote sharing one identity. The raw API command gained custom headers and the ability to send a binary file as the request body, which makes it usable for the endpoints that were previously out of reach from the command line.
Check three version numbers before you schedule this
The minimum Go version moves to 1.26, which only matters if you build Incus rather than consuming packages. The two that matter to everyone running OVN are the minimums for Open vSwitch, now 3.3.0, and OVN itself, now 24.03.0. Those are platform level dependencies, they usually come from your distribution rather than from the Incus repository, and discovering them mid upgrade is how a routine bump turns into an evening.
Beyond that, the honest summary of 7.4 is that its headline feature is deliberately less ambitious than the thing it replaces, and better for it. Snapshot streaming does not need to understand the workload. It just needs the filesystem to be able to describe a difference, which ZFS and Btrfs have always been good at. That is a much smaller surface to get wrong than reconstructing a process tree on another machine, and it is why this is the version worth upgrading a container host for.
Sources and further reading
- Incus 7.4 has been released, Linux Containers discussion forum, August 28, 2026
- Incus 7.4 Adds Near-Live Container Migration for ZFS and Btrfs, Linuxiac, August 30, 2026
- Incus v7.4.0 release notes, lxc/incus on GitHub
- Migration, Incus documentation
Frequently asked questions
How is this different from real live migration?
Real live migration moves memory. CRIU freezes the processes, dumps their state, transfers it and restores it on the destination, so in principle nothing is ever stopped for long. Near live migration in Incus 7.4 moves only the filesystem. It sends incremental ZFS or Btrfs snapshots while the container keeps serving, then stops the container, sends one last delta and starts it on the other side. Connections are dropped and processes restart. What you buy is that the transfer window shrinks to the size of the final delta instead of the size of the whole root filesystem.
Why is it limited to ZFS and Btrfs?
Because both filesystems can compute and stream the difference between two snapshots cheaply, which is exactly what an incremental transfer needs. The Incus developers say the other storage drivers lack an efficient snapshot transfer mechanism suited to this, so there is nothing to build on. If your containers sit on directory, LVM or Ceph backed storage, this feature does not apply to you and the ordinary stop, copy, start path is still what you get.
What commands does it use?
The refresh path is exposed through the existing move command, as incus move with the refresh option, so it fits into whatever tooling you already wrap around migrations. For cluster maintenance there is a refresh-migrate mode for evacuations, which is the case that matters most in practice: draining a node before a kernel upgrade without a long freeze on every workload it hosts.
What else changed in this release?
A fair amount of plumbing. Restricted projects can now reach selected networks in the default project through restricted.networks.access. Network zones gained DNS NOTIFY, so secondary servers refresh immediately instead of waiting out a timer. Virtual machine disks and network devices gained burst read and write limits, and bridged, point to point and routed NICs gained a configurable queueing discipline. Ceph RBD picked up a librbd backend option, and cluster wide shared storage pools can now be recovered through incus admin recover.
Are there upgrade prerequisites?
Yes, and they are the kind that bite in automation. The minimum Go version moves to 1.26, which matters if you build Incus yourself rather than taking distribution packages. The minimum Open vSwitch version moves to 3.3.0 and the minimum OVN version to 24.03.0. If you run OVN networking on an older platform release, check those two numbers before you schedule the upgrade, not after.