Which means that “fleet management” running on premises will be going away.
And I thought running TrueNAS was all about data sovereignty.
2 Likes
At least for me it went until I upgraded from FreeNAS 9 to FreeNAS 11, which meant building a whole new system since I suddenly needed a lot more RAM. Back then the old mantra of “1 GB of ECC RAM per 1 TB of managed storage” was in full force. Interestingly back when I started while FreeNAS would run (with some apps even) in 512 MB of RAM, the FreeNAS installer would not. I had to use the method of imaging FreeNAS to the boot drive.
What do you mean by pre-ZFS? NanoBSD for the boot volume? Yes, BTDT. But as far as I know FreeNAS has always used ZFS for the storage pool(s).
I have been running it since FreeNAS 8, deployed every application I could in “experimental” VNET jails, VMs were Virtualbox based at the time so I wasn’t interested.
After 9.x FreeNAS Corral happened and I must say that my experience was nowhere near as bad as it seems to have been for some or even the majority of folks. All in all even Corral was rather smooth sailing. Lacking jails I reworked all my services into dedicated VMs, based on FreeBSD of course, and e.g. ran a DHCP server VM with half a gig of memory. Bridged networking worked great as is still the case with TN CORE.
TN CE has a long way to go - not in terms of features, but in terms of robust bridged networking, service isolation, etc. This is of course mainly due to Docker’s brain dead networking implementation. I am curious how you intend to solve that.
I do not “hate” Linux. But for anything that can run smoothly on FreeBSD, like e.g. Nextcloud or more or less any “LAMP” application, I absolutely prefer the clean and flexible implementation of jails over any other container technology.
Also I do not personally run VMs on CE. It is my main platform for anything that by the decision of the project in question is strictly Docker based. I could use a plain Linux system with e.g. Dockge but if I run TrueNAS I gain snaphots and replication to my other TrueNAS systems without rolling my own version of all of that. Plus SNMP etc.
If I may add a final word of criticism or suggestions for improvement: I have a career in IT now lasting almost 4 decades. My primary concerns with the direction of TrueNAS at the moment are:
- bring back LLDP
- improve SNMP
- improve reporting via what in CORE used to be graphite protocol - no idea (yet) what CE uses
- if you really terminate TrueCommand - offer an on-premises alternative
Monitoring is probably the single most important thing in an enterprise context. SNMP no matter how ancient and old fashioned it is, is ubiquitous. Same for LLDP. The removal of the latter really shocked me. Have you folks ever run a data centre?
Kind regards,
Patrick
1 Like
In its very early days, it also supported UFS volumes–though that may have been pre-8.0.
1 Like
It still supported them in 9. At some point they changed that to “you can keep what you have, but new pools have to be ZFS”. Much like now where I have a ZFS pool using GELI encryption still, but I can’t make new ones that way, and I have to remake that in native ZFS encryption when I change to TrueNAS CE.
Pls explain why/how you use, need, trust LLDP!
It shows me which device and port is on the other side of an Ethernet link. If you have a couple of dozens of servers to manage and a contractor for the switches that is invaluable.
1 Like
I just checked and you can add a graphite exporter on the reporting tab, is that what you’re looking for?
Yep, that’s good, actually. I’d take telegraf or anything more modern, too. Thanks.
Will there be OpenZFS 2.4.0?
The Release notes for the beta still list openzfs 2.3.0…
We choose OpenZFS versions early in the development cycle for a new release. So 2.3 in Goldeye.
2.4 is planned for Halfmoon.
1 Like
“1 GB of ECC RAM per 1 TB of managed storage”
This was only a mantra because it is blindly repeated over and over again by people who didn’t know any better.
As to ECC memory, it’s never been required or enforced, just recommended.
3 Likes
I recently learned that IX is removing Incus… I have extreme fatigue after the crazy flip flopping between containerization approaches. Please just pick something and commit to it!
Some questions:
- What is the future of Incus system containers moving forward?
- Why has Incus been abandoned in favor of a direct integration with libvirt?
- Will we get system and app container support?
- What’s the deal with Docker and LXC co-existing given that libvirt can run OCI/app containers?
Good questions where the answers have evolved with the software.
There is no such thing as an Incus System Container… its an LXC (Linux System Continer). LXC is still supported in 25.10. Migration does not require any user admin.
Incus directions were counter to TrueNAS preferences. TrueNAS needed a software layer that acted as a reliable slave. In the end libvirt was more reliable in that mode. TrueNAS still supports Incus clusters via an API integration
Yes, 25.10 has system (LXC) and app (docker) containers. There is no conflict.
In general the transition from Incus to libvirt does not change TrueNAS functionality or migration… its does clean-up the internal software and simplifies some administrative actions.
1 Like
25.10-RC.1 is being prepared for launch…
Thanks for all the BETA testing.
6 Likes
Thanks for the response and clarification. Why use Docker and libvirt at the same time? Doesn’t libvirt have full support for app containers?