As you are all aware, Classic Virtualization is returning in Fangtooth 25.04.2.
Our QA testing is ongoing and is expected to be complete within 2 weeks.
In the meantime, any developers and tester are welcome to test with the Nightly version available here. in the TrueNAS -scale-fangtooth-nightly folder.
Production systems SHOULD NOT use the nightly.
With the return of Classic Virtualization, VMs in the Instances section will still start/stop/restart, but you cannot create “new” ones in there. New VMs should be created in the Classic Virtualization UI.
That is a brilliant result for those early-adopters who trusted iX’s technical strategy and who have already gone through the pain of migrating all their VMs to Incus.
However, now that any new VMs will use libvirt giving them a mixed environment, should these early adopters feel that they have to migrate all their VMs back to libvirt?
And also a few questions about GoldenEye:
Will GoldenEye introduce any new virtualisation drivers other than the existing libvirt/Incus drivers, and if so will VM migration to these new drivers then be a requirement for upgrading to GoldenEye?
Will GoldenEye support creation of new VMs in both libvirt or Incus?
When upgrading to GoldenEye, will users be expected to migrate from libvirt to Incus or from Incus to libvirt?
The era of Incus VMs on TrueNAS. What a remarkable history. I have so many fond memories for years and years of using Incus VMs on TrueNAS. I suppose we need to learn to let go when something has outlived its usefulness.
If I understand correctly 25.04.2 cannot create new Incus VMs through the GUi (through CLI maybe?), but existing ones still work.
And it seems that if one has successfully moved to 25.04.0/1 and Instances VMs, nothing forces to update to 25.04.2. Read the release notes carefully and decide, and all that sort of things…
Short but wild so far… Yet, if I understand correctly Incus was first introduced to manage “sandboxes” and will keep on for this role. The question is what will eventually prevail for VM management.
Co-existence of existing Instance VMs and Classic virtualization VMs
Only Classic VMs can be created in 25.04.2 for 2 reasons:
It avoids the complexity of creating VMs in either approach. This reduces the number of test cases and corner cases. (doing it via CLI is untested)
The Classic VMs have a known automigration path to Goldeye. Instance VMs still have some work and may noy migrate automatically in all cases.
Goldeye discussion will be done after Goldeye is completed. That will include discussion of converting VMs if needed. Nightlies are available for ongoing testing.
I am trying to read the libvirt docs, but I must say while I understand Incus docs quite well and it was easy to follow, libvirt seems much harder. I guess its because libvirt manages many more hypervisors so its much more complex.
So if I understand it correctly libvirt-lxc has nothing to do with LXC and any knowledge from original LXC/Incus is not transferable. This is quite the surprise.
I think I would feel safer using the original LXC, which is the same Proxmox uses and which seems to have more understandable docs.
So those “early adopters” and naive users who upgraded to Fangtooth and then found that they had to migrate their VMs will now likely have to migrate their VMs again when they upgrade to Goldeye, whilst those who were more cautious won’t have any such difficulties.
That is a truly great way to encourage early adopters to beta test future “experimental” functionality that is the core of a major full release.
Good point.
Incus is mainly meant as management layer for LXCs, even though it can do also QEMU very well.
So as you say, iX could keep Incus for LXCs because thats what its best for.
They could also keep libvirt for VMs.
And after these things are stable, they could without any rush decide if they will try to manage VMs via Incus or keep VMs long-term on libvirt.
The key point is no rush, slow and steady and without removing old things before the new one is ready.
But as things are now I dont see any clear message what the plan is. I try to deduce it from the little I hear.
If iX plans to move to libvirt-lxc, then Im afraid.
To me it would seem like rushed decision that doesnt make sense to me. Especially if all it takes is just finish the Incus integration for LXCs and it can work nicely. No need to abandon it.
Currently there is just little info without any specific plan announced.
I wonder if thats because as announced in podcast, they will speak only about features in Truenas and stop talking about the backend stuff.
Something like “Instances/containers will work in Truenas but we wont tell you if it will be done via Incus/LXC or libvirt-lxc because we dont discuss backend anymore.”
Its hard for me not to discuss backend, because I usually first look what backend can do and then ask if it can be integrated into middleware/UI.
Thank goodness. It’s simply awesome for hosting my SSL scripts.
Now that I’m back from vacation and curious to install a VM to host HAOS, what is likely the “safest” approach re: not ending up with a config / container / whatever that is going to get nuked by a change in management direction?
I have so many fond memories for years and years of using Incus VMs on TrueNAS. I suppose we need to learn to let go when something has outlived its usefulness.
