Re: [RFC storage, qemu-server] optional multi-volume / consistency-group snapshot hook

Re: [RFC storage, qemu-server] optional multi-volume / consistency-group snapshot hook

[Ciro Iriarte]

I under-sold this in the mail this morning. I said the `cg` tag maps onto the two
backends I can test, Ceph and a VSP array. ZFS is a third.

I had assumed ZFS atomicity meant `zfs snapshot -r` over a subtree, which would
only give you a group if the volumes happened to share a parent. That is wrong.
`zfs snapshot` takes a list, and they land in one transaction group wherever the
datasets sit:

    # zfs snapshot rpool/cgA@cg1 rpool/cgB@cg1
    # zfs get -Hp -o value createtxg rpool/cgA@cg1 rpool/cgB@cg1
    7830984
    7830984

Same createtxg, so the same instant, for an arbitrary set rather than a subtree.

Checked it end to end on zvols, since that is what a VM disk is on zfspool. Two
64M zvols with distinct random content, snapshotted in one command, both then
overwritten, then cloned from the snapshots:

    pre-snapshot   A=1f5d99cb...  B=ca4d6039...
    post-write     A=b9165b06...  B=98949c0d...
    clone of @cg1  A=1f5d99cb...  B=ca4d6039...

Both clones came back with the pre-snapshot content. So the group snapshot caught
both volumes before the writes, and cloning from its members works -- the same
grouping serves snapshots and clones.

That answers the scope question I asked in the first mail. This is not a
two-backend feature for Ceph and vendor arrays: zfspool can do it with a command it
already runs, and zfspool is far more common in the field than either. So the tag
would be doing real work for in-tree storage, not just for out-of-tree plugins
like mine.

The ones that cannot, so nobody has to check: LVM thick and thin have no multi-LV
atomic snapshot primitive in dm, so `lvcreate -s` per LV gives different instants
unless the caller freezes around them. btrfs snapshots are per-subvolume and PVE
uses one subvolume per disk, so no arbitrary grouping there either.

Thanks,
Ciro