[libvirt] ZFS backend does fail if used on non top level pools

[Daniel P. Berrangé]

On Wed, May 02, 2018 at 09:36:10AM +0200, Christian Ehrhardt wrote:
> 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?

I don't really know anything about the ZFS pool in libvirt, but
it superficially looks like a genuine libvirt bug we should try
to fix.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|