Knowing when to use a vm and when to use a container is sometimes an opaque problem.
This is one of those cases where a VM is a much better choice.
> OCI images can now be uploaded manually or downloaded from image registries, and then be used as templates for LXC containers.
It has improved as of newer kernel and docker versions but they were problems (overlayfs/zfs incompatibilities/ uid mapping problems in docker images/ capabilities requested by docker not available in LXC, rootless docker problems,...)
Depending on your hardware platform, there could be valid reasons why you wouldn't want to run Frigate NVR in a VM. Frigate NVR it works best when it can leverage the GPU for video transcoding and TPU for object detection. If you pass the GPU to the VM, then the Proxmox host no longer has video output (without a secondary GPU).
Unless you have an Intel Arc iGPU, Intel Arc B50/B60, or fancy server GPU, you won't have SR-IOV on your system, and that means you have to pass the entire GPU into the VM. This is a non-starter for systems where there is no extra PCIe slot for a graphics card, such as the many power-efficient Intel N100 systems that do a good job running Frigate.
The reason why you'd put Docker into LXC is that's the best supported way to get docker engine working on Proxmox without a VM. You'd want to do it on Proxmox because it brings other benefits like a familiar interface, clustering, Proxmox Backup Server, and a great community. You'd want to run Frigate NVR within Docker because it is the best supported way to run it.
At least, this was the case in Proxmox 8. I haven't checked what advancements in Proxmox 9 may have changed this.
There are some camera stability issues which are probably WiFi related (2.4 GHz is overloaded) and Frigate also has its own issues (e.g. with detecting static objects as moving) but generally I’m happy with it. If I optimize my setup some more I could probably get it to a < 50% utilization.
2.4 GHz sucks though. Wish my mesh allowed me to use multiple 2.4 GHz channels concurrently or per node.
This is changing, specifically on QEMU with virtio-gpu, virgl, and Venus.
Virgl exposes a virtualized GPU in the guest that serializes OpenGL commands and sends them to the host for rendering. Venus is similar, but exposes Vulkan in the guest. Both of these work without dedicating the host GPU to the guest, it gives mediated access to the GPU without any specific hardware.
There's also another path known as vDRM/host native context that proxies the direct rendering manager (DRM) uAPI from the guest to the host over virtio-gpu, which allows the guest to use the native mesa driver for lower overhead compared to virgl/Venus. This does, however, require a small amount of code to support per driver in virglrenderer. There are patches that have been on the QEMU mailing list to add this since earlier this year, while crosvm already supports it.
I'm not exactly sure how the outcome would have changed here though.
https://pve.proxmox.com/wiki/FAQ
> While it can be convenient to run “Application Containers” directly as Proxmox Containers, doing so is currently a tech preview. For use cases requiring container orchestration or live migration, it is still recommended to run them inside a Proxmox QEMU virtual machine.
It's blazing fast and I cut down around 60% of my RAM consumption. It's easy to manage, boots instantly, allows for more elastic separation while still using docker and/or k8s. I love that it allows me to keep using Proxmox Backup Server.
I'm postponing homelab upgrade for a few years thanks to that.
Lesson in here somewhere. Something about about a toaster representing the local intelligence maxima?
For even n>2 you define a tie breaker node in advance and only the partition connected to that node can make a quorum at 50%. For n=2 going from no quorum to quorum requires both nodes but losing a node doesn't lose quorum, and when you lose a node you stop, shoot the other node, and continue. For split brain the fastest draw wins the shootout.
I bet there is still space for a race condition there.
Most homelabbers ignore recommendations because if anything breaks nothing of corporate value is lost and no one's gonna lose their job.
So I went for the AOOSTAR NAS mini-pc as a "proper" solution. Ended up with two machines, so why not join them into the cluster!
Probably can chuck proxmox on a RasPi somewhere, just for quorum purposes :)
Proxmox virtual environment 9.1 available - https://news.ycombinator.com/item?id=45980005 - Nov 2025 (56 comments)
* https://pve.proxmox.com/wiki/Upgrade_from_8_to_9
And "Known Issues & Breaking Changes (9.1)":
Has anyone here found a stable way to handle USB / PCIe device identity changes across updates or reboots?
That part always feels like the weak point in otherwise solid Proxmox setups
"- do interns get Glocks? - no, they all share one"
No amount of scripting with systemd path units, pre and post hooks, udev rules could make those work reliably (for me).
Solution, or workaround, after much headdesking: put services into a VM, map USB device by vendor:device ID, done.
If anyone could shed a light into why that is possible with a VM but not a LXC container, I’d be thankful!
[0]: https://pve.proxmox.com/pve-docs/chapter-qm.html#resource_ma...
Any debian system (proxmox is based on debian) would have broken in a similar (if not the exact same) way.
My cluster went from 6 to 7, 7 to 8 and recently 8 to 9, along with Ceph - all without a single problem.
Given it’s more or less Debian underneath, not too surprising I’d say? Granted, there’s always a chance for something to go sideways, however, it’s unlikely you’re the first person to encounter this problem and if you check their forums, you should find a solution.
Pretty unhappy about the Broadcom acquisition as VMWare previously seemed to care about the homelab market and recognized the value created by letting hobby admins learn their tools. That's going away now and Broadcom hopes the locked in market will provide enough income to suit their short term goals.
Anyway, I switched to Proxmox 9 in my lab this year and couldn't be happier. It's so much more powerful, flexible, and intuitive after one spends a few days in the UI. I ported all my VMs over and things are rock solid and better than ever under Proxmox.
My local systems team at $CORP knows of Proxmox but acknowledges nothing will be changing soon with our environment. But time will tell I suppose.
evanjrowley•2mo ago