I’ve been struggling with getting a VM backend in virt-manager to work properly for a while now. Normally NFS qcow2 works fine, but for some reason it didn’t and I really wanted to avoid the current setup becoming a permanent temporary fix, where the temp fix is, e.g. a windows VM having NTFS on qcow2 vdisk on ext4 / xfs on iSCSI on a zfs zvol.
@redocbew you might be interested in this post, maybe.
I realized that for certain VMs with local zfs, I was just passing through the zvol volume directly with /dev/zvol/pool/whatever-vol as a source disk, instead of using qcow2. It didn’t occur to me that I could just login to iscsi portal and instead of formatting and mounting a local fs on the hypervisor, just passthrough the whole disk sdX to the VMs, just like I’m doing zvols. This is actually the same method of editing the vm.xml file as used by Wendell’s Fedora 26 Ryzen passthrough guide.
After doing a zfs send of a VM that doesn’t get powered on often from local nvme zpool to my nas spinning rust zpool and modifying the xml, started the vm as normal. The VM won’t need fast local storage and is basically “archived” for all intents and purposes. To make sure I wasn’t just booting off the local copy somehow (the config can lie - although I could hear the rust spinning when powering it on initially), powered off the VM, zfs destroyed the local copy and started the VM flawlessly again.
The xml part looks like this
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<!--
discard='unmap'/>
-->
<source dev='/dev/sdX'/>
<target dev='sda' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
Quite happy with my realization, but the shortcoming right now is that the disks might have random mounting orders. I have at least 3 iscsi targets for this host alone and another one or two for another host. Sometimes the 500GB disk is sda, sometimes sdb. Maybe I’m doing iscsi wrong, I have a target for each lun and I treat each target as a disk. This is because I want the ability to later orchestrate a target change via the auth group with a simple service reload to switch the host it is running on.
I’d like to find out how to add a custom WWN to the iscsi LUN, so I can assign /dev/disk/by-id instead of /dev/sdX in the qemu vm xml file. @diizzy maybe you know something, since I’m using freebsd ctld for the iscsi target config.
With this out of the way, now I’m having trouble thinking of a good solution for containers using a similar block device backend, not sure if there is a driver for something like this. Worse case, I can just fallback to individual nfs share per container, to be able to just zfs snap the fs.