[pve-devel] Integration of FreeNAS iSCSI target initiator in Proxmox Enterprise repo
Michael Rasmussen
mir at datanom.net
Wed Jun 3 18:06:18 CEST 2020
On Wed, 3 Jun 2020 16:54:17 +0200
"bsd at todoo.biz" <bsd at todoo.biz> wrote:
>
> A lot of time has passed since version 9 of FreeBSD / FreeNAS. Six
> years to be precise.
>
The version numbers was for explanation purposes only.
BTW. When FreeNAS soon will vanish an be consumed be TrueNAS what
happens then? Will it be a closed and commercial product only?
> iSCSI on FreeBSD is used by very large corporation (Gandi not to
> name them https://www.gandi.net/en <https://www.gandi.net/en> is
> hosting all it's VM using FreeBSD + Linux on the initiator side) with
> an excellent level of stability.
>
I have nothing against FreeBSD on the contrary I have very much fun
using FreeBSD myself (For one usecase I am addicted to pfSense). Only
shortcoming in Proxmox realm in the past was the very non enterprise
iSCSI implementation (istgt) which was replaced by cltd, a very fine
iSCSI implementation, but limited to 1024 LUNs per target in the past
but according to your links has since increased. (By the time I was
looking into to this I had numerous discussions with the developer
about this issue and I promised to inform me personally when he removed
the limitation - I haven't heard from him)
> Solution derivated from Illumos are either overpriced, closed source
> and scarcely used or abandoned (if not all at the same time).
>
This is where you I misinformed ;-) Illumos is truly FOSS an lives
well. Commercially with SmartOS, but not closed source since all
patches are sent upstream. The non-commercial branch of Illumos also
lives well as OmniosCE and are well maintained by Andy and Tobias to
mention a few (I have a small part as well ;-). I think you are
thinking of Solaris as in Oracle Solaris which is definitely on the
usual way to desintegration as all other stuff Larry gets his hands on.
You should also remember that all ZFS development, apart from the black
caves near Redwood City, is done in OpenZFS and all current
implementations apart from Oracle uses the same source tree.
> I think that It might be time to re-considering FreeBSD as a
> potential stable solution to host iSCSI targets. Considering the very
> important efforts FreeBSD has made to implement ZFS and stick to the
> OpenZFS standards.
>
This has never been my attitude. FreeBSD is rock solid an has been for
decades.
>
> This is not true.
>
> The limit that you are mentioning here has been overridden by a
> tunable parameter.
> https://www.freebsd.org/cgi/man.cgi?query=ctl&sektion=4
> <https://www.freebsd.org/cgi/man.cgi?query=ctl&sektion=4>
>
> It turns out that this patch has been developed by one of my fellow
> developer couple of years ago to bypass the limitations of 1024 LUNs
> that you mentioned.
>
Do you have any personal experiences with raising the number of LUNs?
Eg. increase it by a factor of 10?
> So It should qualify to be selected as an enterprise grade solution
> to host iSCSI target.
>
> The fact that some developers are patching Proxmox code to allow *BSD
> / FreeNAS to perform is a sign that there might have a need for such
> tool.
>
> So beside this max luns problem, what else seems to be causing
> problem with the BSD target ?
>
The LUN limitation was my only objection when I stopped to develop the
storage plugin. It should be rather easy to write such a plugin using
the istgt code an replace the iSCSI part with cltd. For a motivated
developer this should not take more than a weekends work :-)
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
https://pgp.key-server.io/pks/lookup?search=0xD3C9A00E
mir <at> datanom <dot> net
https://pgp.key-server.io/pks/lookup?search=0xE501F51C
mir <at> miras <dot> org
https://pgp.key-server.io/pks/lookup?search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
Quid me anxius sum?
[ What? Me, worry? ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20200603/a6b9f282/attachment.sig>
More information about the pve-devel
mailing list