Repro without disks or other HW dependency:
$ apt install zfsutils-linux
$ fallocate -l 100M /tmp/zfs
$ sudo zpool create zfs /tmp/zfs
$ sudo zfs create -V 10M zfs/vol1
You can use that as a disk just fine:
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/zvol/zfsmirrortest/vol1'/>
<target dev='vdc' bus='virtio'/>
</disk>
But using disks "through" libvirt pools had a known issue - see bug 1677398
This is a known issue, but implementation is rather complex and benefit low.
Those that used it so far added custom rules to allow access as needed.
As outlined there (until implemented) you'd usually have the option to either use it without the pool feature or to allow certain paths for your system in the virt related apparmor rules.
That said the TL;DR zfs !pools! never worked so far unless you manually configured the above.
Therefore I'd not expect zfs-pools to work now as-is.
I trying to get to the "volumes seen but then lost" that you described still.
$ 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
Name Path
vol1 /dev/zvol/Xzfs/images/vol1
From here I:
1. installed virt-manager - still ok
2. started virt manager - breaking it
So far I can at least "confirm" your issue already.
I found no apparmor issue (the known issue comes later when the guests start not from libvirt).
But I found in the libvirt log this:
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
I assume this is what virt-manager triggers in libvirt every time, but I don't know the entry point yet. Need to search for it once I'm back (one day out tmrw).
I know you had some of your setup before upgrade, did you have tweaked it to work with zfs pools before? If that was the case I'd be much more concerned.
in general (even thou I think pools won't work) I'd not want virt-manager to clear the pool view, in fact I'd expect libvirt to keep working and just the start of the qemu to fail (due to the apparmor denial).
Repro without disks or other HW dependency: zvol/zfsmirrort est/vol1' />
$ apt install zfsutils-linux
$ fallocate -l 100M /tmp/zfs
$ sudo zpool create zfs /tmp/zfs
$ sudo zfs create -V 10M zfs/vol1
You can use that as a disk just fine:
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/
<target dev='vdc' bus='virtio'/>
</disk>
But using disks "through" libvirt pools had a known issue - see bug 1677398
This is a known issue, but implementation is rather complex and benefit low.
Those that used it so far added custom rules to allow access as needed.
As outlined there (until implemented) you'd usually have the option to either use it without the pool feature or to allow certain paths for your system in the virt related apparmor rules.
That said the TL;DR zfs !pools! never worked so far unless you manually configured the above.
Therefore I'd not expect zfs-pools to work now as-is.
I trying to get to the "volumes seen but then lost" that you described still. Xzfs/images/ vol1
$ 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
Name Path
vol1 /dev/zvol/
From here I:
1. installed virt-manager - still ok
2. started virt manager - breaking it
So far I can at least "confirm" your issue already. size,free, allocated Xzfs/images) unexpected exit status 1: cannot open 'Xzfs/images': invalid character '/' in pool name
I found no apparmor issue (the known issue comes later when the guests start not from libvirt).
But I found in the libvirt log this:
error : virCommandWait:2601 : internal error: Child process (/sbin/zpool get -Hp health,
I assume this is what virt-manager triggers in libvirt every time, but I don't know the entry point yet. Need to search for it once I'm back (one day out tmrw).
I know you had some of your setup before upgrade, did you have tweaked it to work with zfs pools before? If that was the case I'd be much more concerned.
in general (even thou I think pools won't work) I'd not want virt-manager to clear the pool view, in fact I'd expect libvirt to keep working and just the start of the qemu to fail (due to the apparmor denial).