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