Yeah agreed, storage management in proxmox gui is very basic borderline non-existent. Ceph fares slightly better than ZFS. But it also seems to take an altogether different approach. Where TrueNAS doesn’t want users poking around in CLI and certainly not installing packages etc - and I can totally see why - Proxmox VE seems to identify more as a layer on top of Debian and you will frequent see staff in their forums recommending users to install packages, fiddle around with config files where the GUI options do not yet exist, etc. When you edit network settings it lets you preview the changes it’s about to commit to /etc/network/interfaces before pushing them through. Heck, there is even an installer script that installs Proxmox VE on top of an already running Debian. You get the drift.
Nevertheless, as a virtualisation environment it’s very feature-rich and robust and my main point is it’s taken them 20 years to get to where they are now.
I’m not committed either way on this question, but that’s clearly how Kris & Co. feel. It’s how Jordan felt, such that he turned in his commit bit. And until zVault really launches, there’s only one FreeBSD-based NAS OS.
Hmmm… this is where I feel iXsystems runs into trouble all the time and hence is exploring HexOS, et al.
By default, iXsystems has made TrueNAS super flexible - lots of tie-ins into pro-grade features like AD servers, Kerebos, etc. that most consumers would not have. Yet, that flexibility is really good at also confusing the living daylights out of casual admins.
Where QNAP, Synology, and ReadyNAS shine is a super simple UI that is not enterprise compliant but gets 90% there with just a few mouse clicks.
So a lot of people use it as a “good enough” file server, especially “prosumers”. But, security is secondary, ditto data integrity. Hence all the pwnage, etc. of those systems as neophytes expose them to the internet and wonder why all their data was replaced with p0rn, torrents, etc.
So I agree with @pmh that the best approach likely is to allow proper jails to be set and then give users the freedom to explore - installing their own VMs from scratch, etc.
A consistent VM/Apps/etc. environment that evolves predictably from one version of the OS to the next would go a long way to allow folk to post advice on how to get things done, for example.
I still remember following along on YouTube with @yorick as he explained all the weird nuances of installing a windows VM on CORE, IIRC. It was quite involved, because there are tons of details that the docs do not cover - and he did.
And this is where I will close out. I believe that the documentation of common App / VM tasks and procedures could benefit a TON from user / company input. For example, always include tutorials on how to properly install an app, ditto common VMs or jails.
If that kind of documentation is missing, then the OS is not ready for release.
I’m not sure I agree here. There are 200+ apps; I don’t think it’s reasonable to expect a tutorial for each of them. It is, though, reasonable to expect that the tool tips (when provided) be meaningful. And probably a link to the official docs for whatever software is being installed.
Hey, like Ed Koch used to say, “If you agree with me on 9 out of 12 issues, vote for me. If you agree with me on 12 out of 12 issues, see a psychiatrist.”
I do a lot of mentoring at work, with a bit of Excel thrown in. Much of what I “program” in Excel has to be explained so that others can follow in my footsteps. By virtue of having to explain it & fielding questions re: same, I also become more cognizant of what does and does not have shortcomings re: ease of use, reliability, etc.
What may seem perfectly understandable for someone well-versed in the dark arts of bhyve, Docker, or even Incus may be completely flubbering for someone like me. If the installation steps have to be explained, the programmer may become more aware of what is and what is not intuitive.
I for one would be happier with a smaller scope of Apps that is well explained than a larger scope that is so hard to install that I cannot hope to get that done in anything but hours of googling info / youtubing / etc. Bird in the bush vs. two on the tree and all that.
But many of the (i) tool tips have so much improvement potential, it’s fairly easy start, i.e. actually make use of the docs already on the TrueNAS site or external resources to link to.
The problem was removing the libvirt management that had been stably working for a long time, and was relied upon, and throwing somthing which, already “awsome” or not, was, by iX’ own admission, unfinished and unstable (in the sense that interface could, and probably would, change).
Keep the two running. When the new kid is out of the school and ready for work, provide a transition and then remove the old system.
Even if users only had one VM to migrate manually, that was one too many.
Outcome as it was done: You and a handful of enthusiasts lament that the “awsome” Incus is being removed for good. Incus got a lot of underserved thrashing in the process—bad reaction should be to the hasty, incomplete, integration. And many onlookers, including those who had no VM and no skin the game, doubt whether TrueNAS is going anywhere in its quest of becoming the grand hyperconverged OS.
That “move fast and break things” ethos is a large part of the problem.
To me, stability is much more important than novelty. Tirelessly improving what’s there takes precedence over new features. Kyoto craftsmanship spirit rather than Silcon Valley fever.
We can agree to disagree on that.
Hopefully the idea of ‘update trains’ transcending versions will be the fix.
For example jump on the Conservative Train and it will keep you on a current version and will not suggest an update to the new version until thats considered stable/6-12 months old.
Funny part: I had no reason to run a Windows VM and only ever did for the tutorials. I did it because it was a challenge that people on the forums struggled with, and because the sheer level of perversion of running a Windows VM on bhyve amused me.
It’s not, and no longer aspires to be from what I can tell. Hence the name change from SCALE to CE. Hyperconverged died when glusterfs did and wasn’t replaced with ceph, and removing k3s cemented it further.
Hyperconverged always also means horizontal scaling, at least in the way I’ve seen it used - and that’s off the table. Likely for good, though, “never say never”.
I know it’s been posted here (i.e., on this forum) before, which is how I know about it, but I’m not sure what I can find quickly. There’s this from 2002:
but what I remember seeing here was more recent (after the FN10 mess) and more definite, as I recall.
See also:
Yes - IMO that is impolite, and reeks of someone who knows there argument is weak and simply wants to have the last word. But of course every time they do this they create just a little more bad feeling, and they do this when it is pointless because we just open a “Continuing the discussion on …” thread and the debate continues but with a little less respect for TrueNAS as an organisation and the TrueNAS leadership as individuals.
Yes - this is what I have been saying for over a year now since the Kubernetes → Docker switchover - that new technologies should be implemented in parallel with existing technologies because…
It makes it easier for users who don’t have to migrate all their apps or VMs in one go and at the same time as the o/s upgrade, but instead can do app / VM migrations at leisure following the o/s upgrade;
It makes it easier for iX because they have far less pressure to deliver a complete solution
It makes it easier to spin out releases when functionality is properly ready - and if you want to spin out releases on a 6-monthly schedule then you can include the new functions that are ready and exclude those that aren’t.
TL;DR - Open this hidden paragraph to avoid needing to read the rest of this section
Some smaller parts of Open Source approaches could IMO be sensibly applied and give benefits to both TrueNAS developers and the community, but many stated benefits of Open Source do not apply here.
There are many many aspects to what we generically lump together as open source, and some apply here more than others.
Collaborative, synergistic technical development - this does not apply - TrueNAS is a closed development even if the source code is available openly. How many of us here have submitted a PR? And how many have had a PR merged?
Peer reviews - TrueNAS probably do this internally, and again with a closed development I doubt very much that community review of PRs would be sensible or beneficial for TrueNAS.
Forkability - the ability to take a copy of the source code and diverge - this is a major major step for anyone to do because the long-term consequences are major, and IME it only happens when a community gets so hacked off (for a variety of reasons - PRs not being merged, license changes, ethical considerations, poor technical direction) that there is sufficient ire and energy to make such a fork work. To avoid ANY doubt, I am NOT, repeat NOT, advocating a fork.
Synergy - synergistic melding of open source technologies is a basic tenet of genuine open source - just look how many different pieces of open source are in the typical Linux distro (inc. Scale) - so how could TrueNAS be used as an open-source building block to something even bigger and better? (See way below for an idea.)
Collaborative, synergistic idea generation and technical planning - this could apply here if TrueNAS were willing, because there is a wealth of general IT and TrueNAS specific knowledge in the community that could be tapped into and which IMO would lead to significantly better outcomes for everyone - but all appearances suggest that TrueNAS has zero interest in tapping into this. If they respond, TrueNAS will undoubtedly say that the Feature threads and voting meets this need, but as I have analysed previously (and commented elsewhere) there isn’t a lot of evidence that TrueNAS takes much notice of these.
Automated testing and continuous integration and use of GIT to enable parallel development of different functions, with integration into the base case / master branch only when the functionality is ready for publication - I have no doubt that TrueNAS uses GIT internally, and I suspect (but haven’t checked) that they do have some automated tests, but I suspect that the cost of developing the breadth of automated tests to be comprehensive has always been perceived as too large to contemplate (both from a coding perspective and from the testing infrastructure that would be needed to undertake all the various types of tests needed - functional, edge, error recovery, integration, performance etc.)
I am completely unclear why TrueNAS folks seem to be unconcerned that many of their senior community members appear to have a consensus on this view, but whilst the technology issues tend to be short-term in nature, this erosion in trust lasts a long, long, long time.
(Aside: In my relative youf [sic.] i.e. about 4 decades ago, I worked for a major international computer company, and for part of that time I worked in a “win-back” unit whose job was to contact all the ex-customers who went to the competition and try to persuade them to come back - and what I learned was that those customers had all been screwed over (e.g. by buying a £multi-million system at full price days before the replacement range was announced at half the price) and that not only had they not forgotten this but the wounds were still open and seeping rather than healed with only scars remaining. When you have a loyal and enthusiastic community, if you start to lose them then you may never get them back.)
There is a lot of logic to this. Enterprises will either have large-scale virtualisation infrastructure and run TrueNAS virtualised, or they will use dedicated hardware - IMO they will hardly ever (if ever) use TrueNAS virtualisation.
Or keep docker and drop the rest - because Apps are used by a far greater proportion of the community than VMs, and this would allow them to focus on filling out the app catalogues a fair bit.
Q: So why not simply remove virtualisation technologies and leave that to e.g. Proxmox or ESX or VirtualBox or Incus? Perhaps…
A1: Because they need the HomeLab users to do the beta testing, and the built-in TrueNAS virtualisation is the only sensible solution for the smaller HomeLab hardware (i.e. those based on appliances (e.g. uGreen) or workstation hardware (old gaming systems) rather than enterprise server MBs).
A2: Because they need ongoing major new versions for marketing purposes
A3: Because where would the fun be for the TrueNAS development leadership if they didn’t have their new technologies heroically to integrate? Plain old NAS functionality is BORING.
TrueNAS should IMO be VERY worried indeed that such a sentiment has widespread belief amongst the community.
But, (making a politically oriented, and humorously intended, point) then again TrueNAS leadership is pretty much all American, and we can all see what the US Government is advocating as an acceptable (if not recommended, if not mandatory) leadership style.
(Note: Edited to put matching phrases together for analysis.
The TrueNAS folks should be just as worried when an emeritus community member (and a top 10 community support person) first says that they are:
abandoning their use of current technology and sticking with previous generation;
abandoning their beta testing and (to a large extent) community support; and
worse still evaluating alternatives.
Yup. Nothing like hammering another nail into the lid especially when sentiments have been expressed about how damaging previous nails have been.
I hope the same, but have almost zero confidence of it happening.
Yes - many homelab users are in this position. But almost zero revenue for TrueNAS (except for the occasional user who has bought TrueNAS hardware).
BUT, providing that you buy suitable hardware, Proxmox with TrueNAS as a VM is a pretty good alternative.
So true. I worked for a US Multinational a decade or so ago, and they decided to change outsourcing from their 3rd generation outsourcer to a new outsourcer - requiring moving all apps in both USA and Europe to new data-centres which they decided to do by building new hardware (some of which was virtualised) and doing a weekend move of data by truck in HUGE portable NAS - and this was easily the biggest cock-up ever and failed to have even halfway decent programme and project management in either the customer or supplier (both of which are major names) and my lone voice wasn’t listened to - it was a fiasco from start to cancellation and probably lost over $1billion in services and hardware, but no heads rolled AFAIK.
Perhaps I am dense, but isn’t the answer to merge Proxmox and TrueNAS Scale and have a single product?
I can imagine the licensing, cultural, technical and human issues with this suggestion. But if we want to imagine what a hyperconverged solution might look like, isn’t this it?
And isn’t this type of synergy one of the supposed major benefits of open source?
I both agree and disagree with this statement.
If you are expecting TrueNAS to do all of this I agree with it - but if TrueNAS genuinely involved the community it would be easily achievable.
If Synology (and other NAS brands) can sell NAS boxes to users and include VM features why wouldnt Truenas?
Well, Incus is basically Proxmox, just without UI.
What I mean is that Incus is the same type of product as Proxmox and if you say “merge Proxmox and Truenas” then its easier to just integrate Incus.
Proxmox seems more like “appliance” while Incus is more like “library” which is easier to integrate to other product.
Thats why I am really sad that Incus is being removed. I hoped that its integration would offer such converged solution that offers both great ZFS storage ability and great virtualization.
But I guess libvirt can do the same? I find its docs not really beginner friendly so its hard for me to fairly evaluate it.
From just first look it seems like really complex and powerful tool that does a lot of things which also means it seems hard to understand. I need to learn about it more.
If the aim of TrueNAS management is to popularize certain features such as Apps and VMs to a wider audience then the documentation and how to guides have to be improved commensurately.
I agree that this could be a great collaboration opportunity between the community and TrueNAS developers - having knowledgeable users walk neophytes through potentially complicated tasks like Jails, Apps, or even VM installs - what to set and why.
What we have at the moment is usually some pretty raw documentation, usually useless tool tips, and unless you already know what you’re doing, ample opportunity to lose hours of time trying to set up something simple like a pihole or unifi server.
If it takes significantly longer to set up a HAOS in a VM than on a RasPi, the battle re: VMs is likely lost. The development team at TrueNAS really ought to approach the problem from a workflow perspective for folk that do not do this kind of work everyday for a living if they want wider adoption.
Some of us still remember FN10, aka FreeNAS Voldemort, aka The Release That Must Not Be Named–and while the latter two descriptions are slightly overwrought and facetious, only slightly so. It wasn’t iX’ first f-up, but it’s probably the biggest to date. To their credit, they recognized the release was a disaster and killed it, and promised to do better in the future. To their further credit, they have in fact done better–though the “do better” bar is on the floor, and you’d need an excavator to get under it.
But what concerned me at the time, and has yet to be adequately addressed, is the series of corporate decisions that led to “ship this POS, even though we know it’s a POS.” Kris’ only answer then (eight years ago) was, “trust us, we’ll do better.”
That release left a stain on iX’ reputation that, in the minds of many of us old-timers, they have yet to recover from. And every incident like this makes that stain darker and more indelible.
