Support for ZFS zvols

[HubbeKing]

It would be nice to support ZFS volumes in addition to LVM logical volumes.

This would allow for using ZFS on Linux as a storage provider for kubernetes, through the kubernetes targetd provisioner https://github.com/kubernetes-incubator/external-storage/tree/master/iscsi/targetd FreeNAS has its own APIs that another kubernetes provisioner uses for a zvol+iscsi storage provisioner, but nothing similar exists for ZFS on Linux as of yet.

As ZFS volumes are still block devices, it should be possible to interact with them just like one interacts with LVM logical volumes as far as iSCSI is concerned.

Interacting with a ZFS storage pool from python could be done with the native zfs-utils shell commands (using the -H flag for scripting mode for the commands that support it) or through a python ZFS library like pyzfs https://github.com/ClusterHQ/pyzfs or pyzfscmds https://github.com/johnramsden/pyzfscmds

[tasleson]

This is an interesting request. I can see the benefit for folks that utilize ZFS. However, for this to be integrated with targetd I believe the following would need to be considered.

1. Targetd should be able to be installed and run without any additional install or runtime ZFS dependencies for the case when ZFS support is not utilized. Could leverage config file or dynamically investigate at runtime.
2. Any interaction with ZFS should be done with something like pyzfscmds instead of pyzfs. The reason being that it's typically accepted that running something in the same memory space needs to have a compatible license. Thus to mitigate any license incompatibility, if the interaction occurs over a command line via fork & exec the license issue becomes moot.

With all that being satisfied, I don't believe there would be any objections to adding this functionality to targetd, PR(s) welcomed.

[HubbeKing]

A good way to handle the first matter would be to simply have two options in the config file: the existing block_pools, which would always refer to LVM volumes, and a new option, zfs_datasets - referring to ZFS datasets where one could create ZFS volumes. Then, if zfs_volume_datasets doesn't contain anything, targetd can just operate as it already does, using existing LVM defaults.

That does raise the question of what to do if both block_pools and zfs_datasets are set, though.

If one uses python's subprocess library one can interface with zfs-utils over command line, so that also deals with the second issue - and since it's in the standard library that adds no install or runtime dependencies, you'd simply have ZFS on Linux as an optional dependency for running in ZFS "mode", so to speak.

[tasleson]

Resolved with https://github.com/open-iscsi/targetd/pull/42