Hi all. I was curious about some of the pros and cons of using Proxmox in a home lab set up. It seems like in most home lab setups it’s overkill. But I feel like there may be something I’m missing. Let’s say I run my home lab on two or three different SBCs. Main server is an x86 i5 machine with 16gigs memory and the others are arm devices with 8 gigs memory. Ample space on all. Wouldn’t Proxmox be overkill here and eat up more system resources than just running base Ubuntu, Debian or other server distro on them all and either running the services needed from binary or docker? Seems like the extra memory needed to run the Proxmox software and then the containers would just kill available memory or CPU availability. Am I wrong in thinking that Proxmox is better suited for when you have a machine with 32gigs or more of memory and some sort of base line powerful cpu?

  • @TCB13@lemmy.world
    link
    fedilink
    English
    19
    edit-2
    5 months ago

    If you know your way around Linux you most likely don’t need Proxmox and its pseudo-open-source… you can try Incus / LXD instead.

    Avoid Proxmox and safe yourself a LOT of headaches down the line. Go with Debian 12 + Incus/LXC, it runs VMs and containers very well. Proxmox ships with an old kernel that is so mangled and twisted that they shouldn’t even be calling it a Linux kernel. Also their management daemons and other internal shenanigans will delay your boot and crash your systems under certain circumstances.

    LXD/Incus provides a management and automation layer that really makes things work smoothly - essentially what Proxmox does but properly done. With Incus you can create clusters, download, manage and create OS images, run backups and restores, bootstrap things with cloud-init, move containers and VMs between servers (even live sometimes).

    Another big advantage is the fact that it provides a unified experience to deal with both containers and VMs, no need to learn two different tools / APIs as the same commands and options will be used to manage both. Even profiles defining storage, network resources and other policies can be shared and applied across both containers and VMs.

    I draw your attention to containers (not docker), LXC containers because for most people full virtualization isn’t even required. In a small homelab if you can have containers that behave like full operating systems (minus the kernel) including persistence, VMs might not be required. Either way LXD/Incus will allow for both and you can easily mix and match and use what you require for each use case. Hell, you can even run Docker inside an LXC container.

    For eg. I virtualize the official HomeAssistant image with Incus because we all know how hard is to get that thing running, however my NAS / Samba shares are just a LXD Debian 12 container with Samba4, Nginx and FileBrowser. Same goes for torrent client that has its own container. Some other service I’ve exposed to the internet also runs a full VM for isolation.

    Like Proxmox, LXD/Incus isn’t about replacing existing virtualization techniques such as QEMU, KVM and libvirt, it is about augmenting them so they become easier to manage at scale and overall more efficient. I can guarantee you that most people running Proxmox today it today will eventually move to Incus and never look back. It woks way better, true open-source, no bugs, no delayed security updates, no BS licenses and way less overhead.

    Also, let’s consider something, why use Proxmox when half of it’s technology (the container part) was made by the same people who made LXD/Incus? I mean Incus is free, well funded and can be installed on a clean Debian system with way less overhead and also delivers both containers and VMs.

    Yes, there’s an optional WebUI for it as well!

    Some documentation for you:

    • @barsquid@lemmy.world
      link
      fedilink
      English
      115 months ago

      I think I was on a previous account the last time I saw you, glad to see you’re still posting. You convinced me to move from Proxmox to Incus a while back. Sure, I had some growing pains, but it’s pretty smooth now.

      I like that I can switch out my distros underneath Incus instead of being stuck on one weird kernel. IME you were absolutely right about that. I’m getting into atomic distros to manage homelab machines. I would not be able to do that on Proxmox.

      I also don’t need to edit a giant Javascript file to remove a nag about enterprise software repos, which is nice.

      • @TCB13@lemmy.world
        link
        fedilink
        English
        45 months ago

        I’m glad to know that I could help.

        I like that I can switch out my distros underneath Incus instead of being stuck on one weird kernel

        This is an interesting take that I never considered before, my experience (be it corporate or at home) is usually around Debian machines running Incus and I never had the need to replace the distro underneath it.

        • @barsquid@lemmy.world
          link
          fedilink
          English
          35 months ago

          Yeah, I think it’s an unusual case, but I wanted to bring it up to support your point about rejecting their kernel and distro. You can put Incus on a lot of different systems. Don’t like systemd? Put it on Void. Want a declarative setup? NixOS. Minimalist? Alpine.

          Do I want to maintain a full operating system just to run this one type of software? No, that’s absurd. I want to choose the distro I want to work with and then have the software work on top of it.

          • @TCB13@lemmy.world
            link
            fedilink
            English
            35 months ago

            You can put Incus on a lot of different systems. Don’t like systemd? Put it on Void. Want a declarative setup? NixOS. Minimalist? Alpine.

            This is great, yeah.

    • @catloaf@lemm.ee
      link
      fedilink
      English
      65 months ago

      In what scenarios have you found Proxmox to be unstable? I’ve had almost no issues with it, despite using it in several unsupported ways.

      • @TCB13@lemmy.world
        link
        fedilink
        English
        25 months ago

        Check the bottom of reply, there’s a link there with my experience over the years.

    • @rottedmood@lemmy.linuxuserspace.showOP
      link
      fedilink
      English
      35 months ago

      Thanks for all this. I’m familiar with Linux and I just think for my need, something like Proxmox is overkill. I do need to learn LXD on its own. Typically I just run binaries of the services I use, and I don’t tend to use docker or other things. I had toyed with the thought of using Proxmox for management purposes because let’s face it management of several on prem and off prem servers can be a pain. But keeping things running fast and smooth (for spouse approval) is important. I’ll look over the links you provided as it’s probably just good for me to learn LXD directly.

      • @TCB13@lemmy.world
        link
        fedilink
        English
        55 months ago

        Typically I just run binaries of the services I use, and I don’t tend to use docker or other things

        That’s essentially what I do in my NAS with LXD, it’s a great use case for it.

        Enjoy.

    • A Mouse
      link
      fedilink
      English
      25 months ago

      As a small homelabber I agree with this. I started with a baremetal and using Docker, and switched to Proxmox, and now over to Incus, actually currently I am using Debian with cockpit + cockpit-machines. I do like Incus, I keep hopping back and forth between cockpit, I need to settle on one.

      • @TCB13@lemmy.world
        link
        fedilink
        English
        15 months ago

        Actually it would be interesting to see cockpit-machines move to Incus as a virtualization backend and support both LXC containers and QEMU VMs tat way.

    • @rottedmood@lemmy.linuxuserspace.showOP
      link
      fedilink
      English
      14 months ago

      Okay, i was able to take some time and play with Incus. i really like it. I had set it up on a clean VPS and attempted to set up Dendrite in a container. I had some issues getting the traffic to route appropriately to the Incus container and I didn’t have as much time to sit back and play with the settings. It was the first time I was set ting up Dendrite and I had a ton of issues with that in of itself, so i just wiped the VPS and installed Dendrite w/o the use of Incus to get a good understanding of how to get it set up correctly and federate it, etc. Now that I know that I think I am going to give this another try. I like the web UI as well, but since i use an iPhone i wasn’t really able to be able to set up the browser with the cert, which in the long run isn’t a big deal. overall, outside of the firewall settings, it was super easy to setup and get moving. thanks again for the recommendation.

    • Possibly linux
      link
      fedilink
      English
      -25 months ago

      LXC is worse than virtualization as it pins to a single core instead of getting scheduled by the kernel scheduler. It also is quiet slow and dated. Either run Podman, Docker or full VMs. Proxmox has a really nice GUI that allows for more advanced management and live transfers between hosts. It also ships with a newer kernel than Debian although it shouldn’t matter as you are using it for virtualization.

      • @TCB13@lemmy.world
        link
        fedilink
        English
        4
        edit-2
        5 months ago

        LXC is worse than virtualization as it pins to a single core instead of getting scheduled by the kernel scheduler. It also is quiet slow and dated. Either run Podman, Docker or full VMs.

        First what you’re saying about the scheduler isn’t even what happens by default, that was some crap that Proxmox pulled when they migrated from OpenVZ to LXC. To be fair, they had a bunch of more or less valid reasons to force that configuration, but again it due to kernel related issues that were affecting Proxmox more than regular Ubuntu and those issues were solved around the end of 2021.

        Now Docker and LXC serve different purposes and they aren’t a replacement for each other. Docker is a stateless application container solution while LXC is a full persistent container aimed at running full operating systems…

        Docker and LXC share a bunch of underlaying technologies at on the beginning Docker even used LXC as their backed, they later moved to their execution environment called libcontainer because they weren’t using all the featured that LXC provided and wanted more control over the implementation.

        For those who really need full systems is LXC definitely faster than a VM. Your argument assumes everything can and should be done inside Docker/Podman when that’s very far from the reality. The Docker guys have written a very good article showcasing the differences and optimal use cases for both.

        Here two quotes for you:

        LXC is especially beneficial for users who need granular control over their environments and applications that require near-native performance. As an open source project, LXC continues to evolve, shaped by a community of developers committed to enhancing its capabilities and integration with the Linux kernel. LXC remains a powerful tool for developers looking for efficient, scalable, and secure containerization solutions. Efficient access to hardware resources (…) Virtual Desktop Infrastructure (VDI) (…) Close to native performance, suitable for intensive computational tasks.

        Docker excels in environments where deployment speed and configuration simplicity are paramount, making it an ideal choice for modern software development. Streamlined deployment (…) Microservices architecture (…) CI/CD pipelines.

        Anyways…

        It also ships with a newer kernel than Debian although it shouldn’t matter as you are using it for virtualization.

        It matters, trust me. Once you start requiring modules it will suddenly matter. Either way even if they ship a kernel that is newer than Debian it is so fucked at that point that you’ll be better with whatever Debian provides out of the box.