Hi,
by discussing on bug [1] we found an issue in the ZFS storage backend.
When one defines a zfs pool through XML (virsh pool-create --build) a top level ZFS pool will be created and works fine. The virsh pool-define-as counterpart to this is:

$ fallocate -l 100M /tmp/Mzfs
$ sudo zpool create Mzfs /tmp/Mzfs
$ virsh pool-define-as --name zfs --source-name Mzfs --type zfs
$ virsh pool-start zfs
$ virsh vol-create-as --pool zfs --name vol1 --capacity 10M
$ virsh vol-list --pool zfs
vol1 /dev/zvol/Mzfs/vol1
$ virsh pool-refresh zfs
Pool zfs refreshed
$ virsh vol-list --pool zfs
vol1 /dev/zvol/Mzfs/vol1

Ok, all fine so far.
But if one wants to use a zfs-FS as sub-pool things work a while but fail as soon as pool info is refreshed.

$ fallocate -l 100M /tmp/Xzfs
$ sudo zpool create Xzfs /tmp/Xzfs
$ sudo zfs create Xzfs/images
$ virsh pool-define-as --name Xzfs --source-name Xzfs/images --type zfs
I ended with the pool not being started (expected after pool-define-as), but then
$ virsh pool-start Xzfs
$ virsh vol-create-as --pool Xzfs --name vol1 --capacity 10M
$ virsh vol-list --pool Xzfs
vol1 /dev/zvol/Xzfs/images/vol1
$ virsh pool-refresh zfs
Pool zfs refreshed
$ virsh vol-list --pool Xzfs
# no output anymore

We happened to find this in the libvirt log:
error : virCommandWait:2601 : internal error: Child process (/sbin/zpool get -Hp health,size,free,allocated Xzfs/images) unexpected exit status 1: cannot open 'Xzfs/images': invalid character '/' in pool name

So it seems the data refresh would need to become aware of filesytems and strip this to the basename before doing the call.

This comes from src/storage/storage_backend_zfs.c

    cmd = virCommandNewArgList(ZPOOL,
                               "get", "-Hp",
                               "health,size,free,allocated",
                               def->source.name,
                               NULL);

# fails

zfs list -Hp -t volume -r -o name,volsize,refreservation Xzfs/images

# would work

zfs list -Hp -t volume -r -o name,volsize,refreservation Xzfs

But there might be more to it than what I see, either more changes needed to fully work with subpools or intentionally not working with them.

For the latter we should still consider improving the error handling, like refusing right away with a reasonable message on "virsh pool-define-as".

I wondered if one with more experience in that area of libvirt would be willing to pick this up or has an opinion why it would not need to be changed that I might be missing?

[1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1767997

--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd