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).

** Changed in: virt-manager (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1767997

Title:
  virt-manager destroys all volumes in libvirt zfs pool

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1767997/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to