No - absolutely NOT appropriate advice though these things are subjective.
Since I don’t have any virtualisation, I think 24.04.1 is probably ready for production use in my own case especially if I wanted to use LXCs.
If I did have EE VMs then I think that it wouldn’t be ready for production use for anyone even less conservative users.
As I stated in the same comment, I think a single grid for 25.04 is incredibly simplistic and misleading.
P.S. I am not sure it is helpful to ask a specific question requiring an answer and then lock the post without allowing any time for an answer to be given. Smacks more of censorship of a discussion critical of iX than sensible stewardship of a community discussion.
I just dont understand all this drama about VMs.
I personally have production VMs on 24.10. Not many, but I still need them working and regularly snapshotted.
When 25.04 arrived I tested it, found out the new VMs are not capable enough yet for me so i just stayed on 24.10 and I am currently waiting.
And that was it… The end.
So from my point of view I dont really understand what the deal is. I am literally the type of user who should be hit the most by this change and screaming loudest. I have production VMs. But I just didnt mindlessly update my system and I decided to wait until new VMs are ready for production. Because of that I dont have any problems and I dont scream about broken VMs.
I then I logically ask, why cant everyone just do it like me?
Why do I see people complaining about new VMs even if they themselves dont even use VMs?
If I was paying customer on Enterprise I would expect everything to be stable and updates seamless in everything without needing to think. Because I would pay iX to think for me.
But I use free version so I expect that I need to think for myself.
And as someone affected by this change I just dont see the problem so it really raises my eyebrows seeing how much drama it creates.
PS: I am not against feedback. For example the feedback made iX bring back old VMs in 25.04.2 which is nice in my opinion. But what I read on forums sometimes really steps into drama territory which I think is just too much.
I mean, it’s not like it’s ever happened before or anything.
I don’t understand how “we’re going to rip out a feature that thousands of our users are using, replace it with something we have so little faith in that we’re marking it experimental, and push that as a major release of our software” is viewed as anything like acceptable. But it isn’t the first time iX have done it and it won’t be the last.
I have a feeling it became “experimental” either when they decided they didn’t have time to complete it before the end of April deadline for release (and releasing to a deadline was more important than getting it right) or when they decided late in the day that Incus itself wasn’t ready for release or after release when users started making it clear that it wasn’t ready for production. In other words this is a rationalisation of a failure.
And in the latest T3 they are calling reviving the old virtualisation “Classic virtualisation” as yet another rationalisation of why they didn’t deliver Incus in parallel with and alongside the old virtualisation as they should have done from the start (and indeed as they should have done with previous technology changes).
IMO it isn’t surprising that they never seem to learn from previous almost identical mistakes when they rationalise away their failures rather than accepting and learning from them.
Not all users read the release notes and then end up with broken systems.
Not all users have test environments.
Not all users are cautious like you and I.
Because iX gives excessive merit to large upgrade numbers, iX appears to bullishly encourage all the above types of user to upgrade knowing that they will likely have production issues as a consequence because iX want the feedback from using such users as beta testers. And their warnings are often buried in obscure pages and not warned about up-front.
But if iX give value to upgrade numbers - then the best way to get users to upgrade is to make it easy and safe for them so that e.g. they don’t have to worry about their VMs ceasing to work and e.g. so that they can migrate from “classic” virtualisation to Incus based VMs at a time of their choosing and not in a rush as part of their TrueNAS upgrade.
Only after users experience the paid of migrating their VMs and there is an outcry do they announce parallel running, which is simply too late for these users to avoid the pain they have already experienced. But what iX do is to rationalize it rather than apologise and / or learn from repeating the same strategic mistakes yet again.
I wasn’t an IT Programme & Project Manager for 3 decades without learning a thing or two about technical strategy and project planning and risk management.
I can totally sympathize with your frustration—I’ve been shocked myself to discover that my VMs were gone after upgrading to 25.04. Could I have prevented this? Absolutely. But I upgraded anyway to try the latest and greatest. Yes, I clicked the “Upgrade ZFS features” button, which pretty effectively burned the bridge back to 24.10. Again—preventable. But I guess I just like clicking “Upgrade” buttons. That’s on me.
I saw the forums light up with feedback about missing VMs, and I recently read that “Virtualization” is expected to return in 25.04.02. That’s great news! If that weren’t the case, I’d probably be planning a downgrade to 24.10 next month. I had faith that iX would bring back Virtualization—and it looks like they are.
At the end of the day, I’m really happy I can use TrueNAS at home for free. It’s the best software I’ve found for keeping my data safe. Given that, I don’t think it’s fair to complain too loudly about the development process, release cycles, or even mistakes. I try to contribute in the ways I can.
I don’t agree with every decision made, but it’s their project—their baby. They’ve got the full picture and a long-term vision in mind.
This is why these diffusions tend to become circular or get lost down rabbit holes… It seems you chose to respond to a minor detail in @Protopia’s line of reasoning rather than the main gist of what he’s saying. I’m not going to paraphrase myself but since this is on the public web I asked ChatGPT for help and I think it did a rather excellent job actually…:
”Protopia’s main point is that iX Systems rushed the release of the new Incus-based virtualization in TrueNAS 25.04 to meet a deadline, sidelined the old libvirt-based system too soon, and now is retroactively trying to justify this by labeling features as “experimental” or “classic.” They argue that this is a pattern of rationalizing failures rather than acknowledging and learning from them. The better approach, Protopia contends, would’ve been to run both virtualization systems side by side (old and new), make upgrading seamless at users’ own pace, and avoid forcing users into a precarious transition tied to the software upgrade cycle.
In short: they believe iX prioritized publishing on schedule over readiness, mismanaged user migration, and continues to excuse these decisions instead of integrating a more conservative, user-friendly rollout strategy.”
And I would add myself. I think this ”pick and mix” strategy that you seem to be driving towards, with users selecting their version depending on different versions’ maturity level of different features, is likely going to end in tears. Others can speculate whether this is actually a deliberate strategy or coincidental or retrofitting (to one of Protopia’s points). That aside - why is it a bad idea? Because if you would apply the same principles to additional areas the next time time (network, storage, management etc) then the version permutations quickly becomes unmanageable for yourselves and impossible to navigate for the users. The only solution would be to modularise, allowing parts to move independently, which is understand is not what you want to do. Which leaves you with the only reasonable option, in my view, to maintain backwards compatibility while you rework or add new features on this 6 month basis. Which is anyway what you were ultimately forced into with 25.04.2, based on the strong reaction from users.
The Incus features have been labelled as experimental on the front page of the release notes for 25.04 since it began. Its also mentioned in every blog on the topic.
Of course, we’d prefer that integration with Incus would have gone more smoothly, but we were careful to provide warnings. This included the text in the blog on the Fangtooth Release.
We did deliberately keep the Electric Eel VM code in tact… which is why we can turn it on in 25.04.2. However, running the two approaches in parallel is not ideal from a UI or testing perspective. It is plan B, not plan A as we have made clear.
Hmmm. So my interpretation of this is that “experimental” doesn’t just mean lacking in comprehensive functionality - it also means that it is potentially a risk to normal operation of other services if a user wants to see if LXCs could meet their needs. This then prompts the question as to why iX would release a major version that has risks of instability for mature services?
I don’t have any wish to use LXCs. Does that make a difference?
If you were so good at warning people, why have I been helping several people recover their VMs by switching back to EE? Surely if they had seen warnings they would have stayed away from Fangtooth?
With respect, after all these threads and testimonials and resolving and troubleshooting 25.04 that is an unbelievably arrogant answer, and unfortunately QED on this:
Also, for me, end of this discussion and I will now have to decide, like everyone else, where all this leaves me with respect to the product going forward.
I’m just requesting that we stick to the facts when making statements.
We did warn users through multiple mechanisms.
Not all users read and acted on those warnings.
We have responded to user requests for bringing back virtualization
Its reasonable to suggest and request that warnings be more obvious (we agree), but its not reasonable to say say we did not warn or that it was retroactive.
So, if we take your specific case, how to do self-assess yourself as a user on the spectrum of Early Adopter to Conservative?
Well, the people who I have helped recover from their Fangtooth upgrade VM woes have all been sensible people who didn’t think they were putting their production VMs at risk - and I personally believe that had they seen relevant warnings, then they would have taken heed - so the likelihood is that they were not warned in any meaningful way that the upgrade would trash their production VMs.
These were real users who experienced real problems - and not just a statistic.
And TBH the above comment is literally an indictment of the callous attitude that iX appears to show towards giving meaningful warnings in a responsible way.
Personally, I consider the non-container functionality of TrueNAS to be both great functionality and extremely stable. It is only how they introduce new technologies that has a track record of being persistently risky, and I am technical enough to keep my ear to the ground and to know and understand the risks I need to shy away from - but I am almost certainly in the minority because IMO the majority of users are relatively non-technical and both unaware of the risks and over trusting of iX to look out for them and prevent an upgrade from trashing their production system.
TL;DR - for me, iX and TrueNAS’s strengths far far outweigh the downsides of new technology introductions, so I have no thoughts whatsoever about moving elsewhere and I am (despite my outspoken views) much more grateful for being allowed to use this great software than the downsides of having to be wary of upgrades. But as I say, I am in the minority.
It’s iX’ good fortune that there’s very little competition in the “F/OSS ZFS-based NAS” space. OMV can do it, kind of, and is also Linux-based. XigmaNAS can do it, and runs on FreeBSD. Napp-it can do it, runs (preferably) on OmniOS, but has a UI out of the '90s. We’ll have to see what becomes of zVault.
