Before handing a domain over, snapshot-libvirt-domains guarded it behind
'zfs get -s local autobackup:libvirt-<domain>' and tested the result for
non-emptiness. That answers neither of the questions that matter.
-s local drops exactly the inherited lines, while zfs-autobackup looks the
property up without -s and resolves inheritance (ZfsNode.selected_datasets
rewrites "inherited from <parent>" to the parent's source, ZfsDataset.is_selected
takes an inherited flag). Configuring the fleet once on the parent dataset - the
normal way to drive zfs-autobackup, and the only way to cover datasets that
already exist without walking them one by one - therefore made zvirt skip every
domain, while the very same backup names handed to zfs-autobackup by hand
snapshotted all of them.
The guard also had no dataset operand, so it asked "does any dataset in the
pools carry this property locally?"; and it tested presence where zfs-autobackup
tests value, so a local =false passed it, and child/parent were misjudged in
both directions.
Drop the guard and let zfs-autobackup answer, since it is the one selecting.
It reports "nothing selected" as exit 255 with a distinctive message, so keep
its stderr aside for the length of one domain, long enough to tell that case
(skip the domain, carry on with the fleet, exit 0) from a genuine failure
(replay the stderr, abort with its exit code). Its own wording is swallowed in
the skip case: it is printed as an error while nothing failed.
Document the selection in the README - the four property values, the fact that
inheritance counts, and the two properties involved (autobackup:libvirt-<domain>
to snapshot, autobackup:libvirt to prune).
This does not cover the case of a domain whose selection misses part of its
storage: the property selects datasets, not domains, and only zvirt knows what a
domain is made of. Tracked in #3.
Closes#2
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014BSA2qQpCr7cY4qDEX7kuX
Nicolas Massé
023618bf62