5 ms·
For me, the killer use case for this is presenting logical volumes to containers. There just has not been an efficient mechanism for a local storage service in
by benlwalker 4y ago
For me, the killer use case for this is presenting logical volumes to containers. There just has not been an efficient mechanism for a local storage service in one container to serve logical volumes to another container on the same system until this. For VMs there is virtio/vfio-user, but for containers the highest performing option until this was NVMe-oF/TCP loopback.
Basically, you can implement a virtual SAN for containers efficiently with this.
- lifty 4y agoVery appealing. Do you think this solution would be comparable in performance with an in-kernel storage driver?
- topspin 4y agoI'd like a built-in iSCSI volume driver for docker, podman, et al. There are third party things (netapp trident[1], etc.) but no generic driver. One would think -- given the ubiquity of SAN boxes populating racks outside of cloud operators -- you could "-v iscsi:<rfc-4173-iscsi-uri>:/mountpoint" a network block device into a container out of the box. I suppose it's difficult to deal with in cross platform way. When you read the golang source for trident you see they're just exec-ing iscsiadm on linux container hosts. [1] https://github.com/NetApp/trident https://github.com/NetApp/trident