I think that this was a golden choice. There’ll likely be much less worry if existing features get to live alongside future plans (experimental) for a release or two before the plug is pulled (if it ever will be).
Gets both worlds of folks happy to upgrade & not lose anything and experiment & bug test, and you guys can toss any UI Experimental or End of Life warnings as you see relevant to set community expectations of what the future will hold & levels of support to be expected.
I suppose that iX will want to pull the plug at some point, to cut on the cost of maintaining two different interfaces to the same functionality, but when Instances are regarded as stable it might be possible to propose automatic migration.
Where we think we can we normally try to do.
In this case, it would have been a good plan, but we did not know ahead of time that both could run simultaneously
Docker and K8S don’t really run simultaneously.
There are user simplicity challeneges sometimes…
LXC is different functionality
VMs are duplicate with subtle differences.
If it was my product I would not put containers (LXC) and VMs (KVM) under the same umbrella (Instances).
I’d keep VMs with traditional KVM because people are used to and expect that and it’s what about every other product (Proxmox and friends) does.
Additionally provide LXC based containers with Incus under - whatever - “Containers”?
Kind regards,
Patrick
From what I see in Proxmox interface they also put VMs and Containers next to each other and only difference is small icon.
So Proxmox does it similarly to this new Instances method.
That, and they’re broken out separately in the list:
The LXCs are listed first (in numerical order), then the VMs. But, as you say, not a great distinction between them.
Both “traditional” and “instance” VMs use KVM. The former then goes through libvirt and the latter through Incus, as do system containers which run on LXC. And I think it is still possible to run system containers on systemd-nspawn, as was (is?) leveraged through jailmaker.
It is libvirt that could go to the chopping block if the plan succeeds, not KVM.
I wish it were more modular, where you could install/update the Truenas system and features independently. I’m not a big fan of the new “per app ips” feature; I’m not fluent in networking and just wrecked my previous setup (it’s now on a port/ip and I can’t access it.) trying to install another app. Actually found this thread while searching for the pre per app ip update so that I can go back and salvage my data without the per app ip update. And I guess I’ll be stuck outdated until they either simplify the per app ip install process or I learn how to navigate networks (which I have no other use for). This is really frustrating. At this point it’s more likely that I recover my data, and look for an alternative to Truenas. In my experience; the community (forums, youtube, facebook, reddit, etc.) hasn’t been at all helpful in my 2 year journey, most of the updates only complicate/break my setup, and it’s not very beginner-friendly in terms of stability/updates/features/etc.
I’m sorry to hear that, but installing system and features independently would cause more issues.
Ironically, the whole idea of Apps is to allow some of that flexibility but not at the feature level.
Have you been following a profile on the TrueNAS software status page… which one?
Fully agree on that one - this felt very odd, as if they “had to” get that release out of the door even tho a feature was clearly not ready for production.
In production I always prefer stability to fast improvement. One year I think is acceptable, plus security updates when required.
On this driver point, yes… maybe. Nvidia likes to drop new video cards every two years. While I used this opportunity to put a 5060 card into a secondary computer from transcoding purposes and put a 1080 card into my TrueNAS server for Plex reasons, some users got hit by this gotcha when they put in a 50xx card.
The quandary is that a enterprise user is extremely unlikely to have Plex/Jellyfin/Emby installed as an app, but a community user probably would. And apps is a secondary function compared to the primary mission of TrueNAS which is a Network Attached Server. While it would be nice for an updated Nvidia driver to be included in the 25.04.2 release, we won’t see it until 25.10.
Would just like to say a massive thanks to the TrueNAS Team for listening to the community and making the decision to move to an annual release cycle. I honestly believe this will massively improve the product long term and also give users much more stability. Thank you 
Sorry for reference 9mins in.
Heck, as long as things are kept separate from nighly, alpha, beta and release, they could be doing rolling releases as far as I’m concerned. I don’t get the “major release” thing anyway. Features should be released when they are ready, updates/fixes should be rolled out when they are ready. No need to bundle things up and release all this stuff twice yearly.
It really boils down to the value of thorough QA and testing.
When the kernel changes and ZFS changes, we need to thoroughly test everything across a wide range of platforms.
The switch to annual is partly driven by the need to extend QA cycle times to improve quality. It’s much better to find bugs in our lab rather than in many user systems.
More info here:
By no means did I mean to imply that QA should be skimped on, but my point is, things should be released when they are ready, rather than based on some artificial release cycle.
e.g. say ZFS brings out a new release a month before the annual release, you can’t rush testing, so it won’t make it into the release. It’s tested, so 2-3 months later, it’s known to work. Now the ready to release ZFS sits on the shelf for 10 months, because there’s no release scheduled until then. If instead of bundling a whole bunch of upgrades and features into one big release, features and component upgrades would simply ship without specific schedule, whenever they are ready, QA wouldn’t suffer. Of course, marketing would have press releases to put out about “new major version…”
That might work if the features and component upgrades never depend on each other in any direct or indirect way, which is rarely the case, and even then, multiplying the number of different configurations out there can quickly evolve to be a support nightmare. NAS is a conservative business, nothing wrong with getting an upgrade 10 months later than possible. If the product was fine for your use-case when you installed it, it does not become less so because a newer version of some component now exists.
Where I work, an important customer sometimes can convince us to release a feature outside of the release cycle. And sometimes we decide to deliver a feature that is unexpectedly lagging later instead of delaying the release because of it. Rolling releases are however not sustainable for critical products installed on-prem (i.e. no rollback by pressing some button) and taking verification&validation seriously.
