TrueNAS Virtualization Plans for 25.04.2

TrueNAS Community Edition makes use of the KVM (Linux Kernel-based Virtual Machine) hypervisor to deliver Virtual Machines (VMs) on TrueNAS systems. The capability to run a full virtual machine on a TrueNAS system has been available even since the early days of FreeNAS, and remains available in the latest releases of TrueNAS SCALE 24.10 “Electric Eel” and TrueNAS Community Edition 25.04 “Fangtooth” - but with some minor differences between the two.

While Electric Eel had a tab for “Virtualization” functionality to manage VMs, Fangtooth introduced “Instances” as an Experimental feature to manage both lightweight Linux Containers and fully independent VMs. While the VMs under both 24.10 and 25.04 share the use of KVM, there are differences in functionality and ease of use, and the change caused challenges for some members of the TrueNAS community user base. At present, the Electric Eel “Virtualization” capability is better suited for full VMs, and as such some users have chosen to remain on TrueNAS 24.10 until a solution was provided that satisfied their needs.

The TrueNAS Community has asked us for a solution to adopt Fangtooth VMs more rapidly and safely, and today we’re laying out the plan for our path forward to quickly deliver on this community request. The Virtualization software from Electric Eel was never fully removed, and will be re-enabled in TrueNAS Community Edition version 25.04.2, in addition to retaining the current Instances screens. In short, the next version of Fangtooth (25.04.2) will support both Virtualization VMs and Instances VMs.

Fangtooth users will be able to set up and manage VMs through either the Virtualization or Instances screens. For the simplest migration to Goldeye, we recommend creating new VMs in the Virtualization screens. Instances VMs and LXC will remain Experimental.

Electric Eel users will be able to update to Fangtooth and seamlessly migrate their existing VMs, benefiting from the many other advances in the ZFS, security, and storage areas. The Virtualization capabilities will be treated as normal, not Experimental. Electric Eel users with VMs are advised to wait for 25.04.2 before updating to Fangtooth.

The Virtualization pane will offer options familiar to those with experience managing KVM-powered virtual machines, including storage controller and device emulation options for older operating systems, including those requiring a BIOS-based boot as opposed to the newer UEFI process.

Users with existing virtual machines will be able to directly upgrade, without requiring any new learning process. Existing Virtualization tutorial resources and configuration guides will remain relevant, and those wishing to explore the new features such as Secure Boot for VMs can continue working in the Instances pane.

Fangtooth systems can later be updated to Goldeye, and all Virtualization VMs will migrate smoothly. Instance VMs will also be migrated, but some manual configuration changes may be required for PCIe or USB devices and pass-throughs. The TrueNAS engineering team will work to minimize the amount of work for users.

Additional details on the virtualization implementation in TrueNAS 25.10 “Goldeye” will be discussed in more detail as it approaches BETA in August.

TrueNAS 25.04.2 will be available at the end of July 2025. We are giving everyone a heads-up as we complete this project. In the meantime, we recommend Electric Eel users with VMs delay their updates to Fangtooth. Users without VMs can update whenever they want.

The TrueNAS software status page will be updated as things change. Kris and I will also be covering this in the TrueNAS Tech Talk podcast later today. episode linked below:

13 Likes

And what will happen with LXCs created under either 25.04.0 or 25.04.1 when upgrading to .2 or to 25.10?

1 Like

LXCs will be untouched and remain under Instances as there’s no equivalent in the Virtualization menu’s libvirt back end.

1 Like

@HoneyBadger This is great news, and it is heartening to know that iX has listened to the community requests for delivery of new functionality alongside and running in parallel with existing functionality (rather than forcing users to migrate VMs as an additional immediate mandatory step at the same time as the version upgrade).

I certainly hope that this becomes a standard part of iX’s approach in the future (at least where it is technically possible - whilst it is for Incus, and iX have said that it probably could have been for Kubernetes → Docker, this may not always be the case).

6 Likes

Will instance VMs be migrated/carried forward as instance VMs? I’m generally happy with instance VMs (including accessing Incus functionality that I know isn’t supported or guaranteed to work moving forward…, and isn’t available under the previous framework)

This is a great decision and glad the conclusion was reached. I was going to skip Fangtooth due to experimental features, but now I will be able to upgrade once that process works. Thanks!

2 Likes

Perfect choice! I’ll actually be looking forward to upgrading & testing instead of dreading setting up my vms again.

I’m not sure how much additional effort this took (I hope not a lot & you guys glued it together with relative ease), but this is the best of both worlds for the community.

So VMs are migrated to the old system again and Containers stay at the new system? Or will the old system just be enabled for legacy support until the new system is considered enterprise ready?

Sounds like I’ll be able to update my big system with 30 VMs sooner rather than later :slight_smile:

1 Like

This sentence is referring to Goldeye, correct?

They will definitely remain experimental in 25.04.2 - 25.10 isn’t decided yet if the Instances menu will be able to shed the experimental tag.

2 Likes

So the VMs with the incus backend will eventually get dropped in a future release? I guess the containers stay with the incus backend and will get integrated into the other menu?

We’re hoping to be able to unify VMs under one path again in the future. Containers will stay under the Instances menu - and they’ll stay Experimental - but the hope is that the VMs will be able to be production-ready, Enterprise, however you’d like to phrase it.

The aim here isn’t a particular back-end, but rather the desired feature set. Kris and I talked about it in the podcast (which is now directly linked in the first post) but there’s definitely some hard work to be done for things like Secure Boot, VNC support, etc.

We’ll be hoping to share more detail after 25.04.2 releases.

I certainly hope Incus is here to stay for VMs. Its better than libvirt once its properly integrated into Trunas.

4 Likes

I hope so too.
I would prefer the VM and Container management unified with incus.

4 Likes

This is good news and buckets of credit for iXsystems for listening to its users. In the recent past there have been plenty of instances (no pun intended) where a vendor ploughed on with an unpopular change regardless of user dissent and with the consequent loss of reputation and user base. I am glad and relieved that iXsystems are not following that path and I am sure their respect for the user base will be rewarded with our loyalty.

TrueNAS is an awesome product and I still can’t believe that we get to use it for free.

I run a number of Windoze 7 VMs which cannot be migrated to Windoze 10/11 and for which also the ISO cannot be instrumented with whatever drivers are required to make them work under the Instances system. I have stuck with ElectricEel 24.10.2.2 and now have an upgrade path to Fangtooth with 25.04.2.

PS: Love the podcast! I have particularly enjoyed the history and would love ot hear more.

2 Likes

tailscale is awesome! one step setup and no dealing with ports and stuff. don’t wanna do that tbh.

i usually don’t use in house exit nodes to limit traffic hops and only ever really use it through my apple tv box when my main server is making weird noises while i’m out and want to check on it through ipmi / ip address rather than the tailnet.

you were asking about tailscale improvements:

  • an option for taildrop would be awesome to enable tailnet users sending files via tailscale to the hardware.
  • every application in the catalogue should have a button to add the tailscale container so we can access each app through the tailnet w/o ports (think immich.tail-net.ts. net). this would also give these connections an ssl certificate and get rid of the annoying setups through trusting private certificates etc.

and okay these next few are a bit of an experimental one buuut :see_no_evil::

  • golinks through tailnet
  • tsidp to use tailscale as the openid connect provider for all apps on the tailnet*.

a few of their community projects and experiments for others here to explore: Tailscale Community Projects

*on that node: can smb use openid connect to authenticate (mac/linux?)

Really appreciate the team taking the feedback on board about the undesirability of having virtualisation experimental in 25.04. Like others I was holding back on upgrading from 24.10 until this was resolved. Looking forward to 25.04.2!

1 Like

Hello!

From the above quoted text and some discussions on the video, I got the impression that libvirt based virtualization (Virtualization VMs) are the long term plan and Incus-based VMs (Instances VMs) will dropped/migrated.
Incus will remain only for LXC containers.

Did I understand correctly?

Thanks for the clarification.

1 Like

As far as i understand it, the longterm plan is for incus to also replace the libvirt backend for vms, but as long as the incus implementation is not at feature parity with the libvirt one, libvirt stays.