I've recently migrated to Incus and am enjoying it so far. Hopefully the good feelings last.

Roughly ten years ago, my homelab consisted of a dozen virtual machines running on SmartOS. I was not familiar with Illumos, and this was before it had a widely available web UI, but it was simple enough to use that these challenges didn't matter much. SmartOS was designed to boot reliably from USB flash storage, allowed me to use all my SATA ports for VM storage, and was my first "immutable" operating system. The primary focus on ZFS storage was another great quality of SmartOS.

Two moves and several years later, it was time to rebuild the lab, and I decided to go with Proxmox because it had decent ZFS support. Experience with Proxmox has been very good too. The GUI, many more virtualization features (in addition to the key ones I care about), and better hardware support through the Linux kernel have kept me on Proxmox for a long time.

Customizing my Proxmox installation always gave me anxiety. How could I defend my hypervisor from configuration drift? I wished there could be an immutable version of Proxmox.

Later on, I learned about govulcheck, which offers a novel dynamic/static analysis hybrid approach to vulnerability management. Nothing else out there does this (without teaming up with some huge company). I began to think that I should favor software solutions based on golang.

Ultimately, Incus (and IncusOS) fit this need very well. My IncusOS hosts excellent and I'm glad I can run Incus itself on most Linux distros - including NixOS!

I'll keep a small Proxmox host around for experimenting with new kernel features (Intel GVT-g / SR-IOV graphics) and old operating systems like Windows XP or anything else that needs special QEMU options.

I get the advantage of fully declarative systems such as Nix, but everything you do in proxmox via GUI can be done via CLI: https://pve.proxmox.com/pve-docs/#_command_line_interface

CLI is first class in proxmox, I use the qm command for managing vms all the time. The networking is also just a file in `/etc/network/interfaces` that I modify with vim as needed.

As people have said proxmox supports cli and api usage as well but a huge part of learning it is just poking the various settings and fiddling with the different options. I never felt the need to go beyond that to automate settings. I don't even cluster distinct proxmox hosts.

Also the mentions and requirements relating AI in the article sound like they are from another world. Did things really come to this? Even if they had, you one can still snapshot proxmox vms as well as host (zfs).

I'm also considering migrating from Proxmox to Incus, but I'd look into IncusOS rather than having to manage the host OS myself.

Good lord, if how they were managing Proxmox with an agent was essentially using Playwright, no wonder they thought there was a problem.

I don't even do that, I go into a shell and run qm commands for more complicated things. And for anything I ask an agent to do, it goes straight to qm and other CLI tools as well.

Weird.

Author here!

All valid comments about the fact that Proxmox is not limited to clicking around in the web UI.

It has qm, pct, config files, a REST API, Terraform providers, and Ansible workflows. My point is not that Proxmox cannot be automated.

Even with that automation, state drift can still creep in when debugging means running one quick command, especially if an agent is allowed to execute imperative fixes that never make it back into the automation framework. It is that, for my setup, I wanted the reproducible configuration itself to be the source of truth.

The thing I care about is not buttons versus commands, but whether I can rebuild the host from version-controlled text files and know that every important change is captured there.

I don't get their argument, I run GeForceNow on one of my Proxmox nodes in metal and there's no problem with it. It's a Debian underneath, after all. They didn't need to switch to NixOS to run Kodi.

Also, do they get PBS using ZFS snapshots? Do they get HA, live migration, shared storage, easy CephOS, easy snapshots, quick cloning? Do you really want to migrate a VM from one node to another using the command line when you're in some serious situation?

Sure, for a homelab this might be OK, but the UI does make things easy for a reason.and it's not a gimmick.

I agree on a lot of the points, though, I just set up a second cluster and it took over 3 work days because of how much repetitive work is needed to do so. To be able to just take a file with instructions, adjust it a bit and deploy would be so much easier.

It's really hard to tell what the benefits of Incus over Ganeti are. The Incus site doesn't really lead with features or benefits that I can see. About the only things I could figure out are that Incus can manage containers and can manage instance creation through cloning a base volume, where ganeti (afaik) always creates volume and populates it. Well, and Incus seems to be MUCH more popular than Ganeti.

I searched the documentation but it wasn't really clear what its live migration and ZFS migration story is, but when I asked Claude to research it, it tells me that it supports live migration via ZFS snapshot replication, which is exactly what I'm looking for. I implemented a ganeti storage driver that does the same thing and am just getting ready to start testing it, but if Incus supports it I might look at moving that direction.

Anyone use Incus live migration with ZFS?

> But fundamentally, Proxmox is built around clicking buttons. It is a GUI-first paradigm.

Uhh, whut? It provides a button-y interface, but you can do everything via config files and `pct` on the command line if you prefer. I know that’s not full nix-style declarative, but you don’t have to mislead to sell me on the advantages of declarative infra.

NixOS has transformed my use of Proxmox. I configure, build, and deploy everything from my nix workstation. I don't need to use the PVE gui at all. Proxmox is just a target, and I've abstracted things enough to where I can deploy the same machines to libvirt on a local machine too. Why would I need to let my agent into my PVE box? I haven't looked at incus, but if I wanted to run the full stack declaratively, nixos and LLMs are so powerful now that I would probably just say to run libvirt and ZFS on nixos natively.