with the demise of ESXi, I am looking for alternatives. Currently I have PfSense virtualized on four physical NICs, a bunch of virtual ones, and it works great. Does Proxmox do this with anything like the ease of ESXi? Any other ideas?

    • kalpol@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      11 months ago

      Admittedly I have not dug too deeply into Proxmox but its learning curve appears kinda steep.

      • anamethatisnt@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        ·
        10 months ago

        There’s multiple guides on virtualizing pfsense in proxmox, but the easiest is to simply pci passthrough the nics you wanna use.
        I do recommend you leave a physical nic for proxmox itself to maintain LAN access to it if your pfsense is down.

        • twei@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          1
          ·
          10 months ago

          There could be driver issues doing this. I had a bad experience with Emulex NICs under OPNsense, Intel OTOH worked flawlessly. Switched back to virtual interfaces tho, as it works about as good as a physical NIC

      • BlueÆther@no.lastname.nz
        link
        fedilink
        English
        arrow-up
        5
        ·
        10 months ago

        its not too bad. i switched from esxi to proxmox about 2 years ago.

        i run a virtualized opnsense with 2 nic’s passed through and another 2 virt, so it can be done

        • bean@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          10 months ago

          Hey! I have been using ESXi about three year now. I have two identical NIC I bought. One for WAN and one for LAN. I also discovered I had to use the onboard LAN port (3rd port!) just to be able to access the web control. (Is that normal?)

          Anyway, I want to move to Proxmox, and then virtualize my OPNSense like I have on ESXi.

          I get so confused by how the adapters should be. Ideally I would love to have the LAN connect to a (dumb) switch, and provide Wi-Fi. But one thing I never tried before is a VLAN to protect the LAN from the Wi-Fi traffic, but still allowing some systems to still work like streaming data from the wired PC on the LAN to the NVIDIA Shield Pro. But then keeping the Alexa/Echo system on a more restricted WiFi.

          Can I do all this? I’m thinking I can, but. The hurdle of learning vlans and configuring the new Proxmox (which I’m pretty damn new to) is a daunting challenge.

          I’m ready to try this though. I have a 4G wireless plus WiFi system to keep the other half happy while I tinker to get it all working.

          Thoughts/Tips? Anyone?

          • BlueÆther@no.lastname.nz
            link
            fedilink
            English
            arrow-up
            1
            ·
            10 months ago

            All doable, you might need a managed or smart switch though

            I have 4 bland at home plus untagged all through proxmox and a smart switch

            • one for wan
            • one for web facing servers
            • one for iot
            • one for guest wifi
            • rest of lab is untagged
          • tofubl@discuss.tchncs.de
            link
            fedilink
            English
            arrow-up
            1
            ·
            10 months ago

            Incus looks cool. Have you virtualised a firewall on it? Is it as flexible as proxmox in terms of hardware passthrough options?

            I find zero mentions online of opnsense on incus. 🤔

            • TCB13@lemmy.world
              link
              fedilink
              English
              arrow-up
              2
              ·
              edit-2
              10 months ago

              Yes it does run, but BSD-based VMs running on Linux have their details as usual. This might be what you’re looking for: https://discuss.linuxcontainers.org/t/run-freebsd-13-1-opnsense-22-7-pfsense-2-7-0-and-newer-under-lxd-vm/15799

              Since you want to run a firewall/router you can ignore LXD’s networking configuration and use your opnsense to assign addresses and whatnot to your other containers. You can created whatever bridges / vlan-based interface on your base system and them assign them to profiles/containers/VMs. For eg. create a cbr0 network bridge using systemd-network and then run lxc profile device add default eth0 nic nictype=bridged parent=cbr0 name=eth0 this will use cbr0 as the default bridge for all machines and LXD won’t provide any addressing or touch the network, it will just create an eth0 interface on those machines attached to the bridge. Then your opnsense can be on the same bridge and do DHCP, routing etc. Obviously you can passthrough entire PCI devices to VMs and containers if required as well.

              When you’re searching around for help, instead of “Incus” you can search for “LXD” as it tend to give you better results. Not sure if you’re aware but LXD was the original project run by Canonical, recently it was forked into Incus (and maintained by the same people who created LXD at Canonical) to keep the project open under the Linux Containers initiative.

              • tofubl@discuss.tchncs.de
                link
                fedilink
                English
                arrow-up
                2
                ·
                10 months ago

                With Incus only officially supported in Debian 13, and LXD on the way out, should I get going with LXD and migrate to Incus later? Or use the Zabbly repo and switch over to official Debian repos when they become available? What’s the recommended trajectory, would you say?

                • TCB13@lemmy.world
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  10 months ago

                  It depends on how fast you want updates. I’m sure you know how Debian works, so if you install LXD from Debian 12 repositories you’ll be on 5.0.2 LTS most likely for ever. If you install from Zabbly you’ll get the latest and greatest right now.

                  My companies’ machines are all running LXD from Debian repositories, except for two that run from Zabbly for testing and whatnot. At home I’m running from Debian repo. Migration from LXD 5.0.2 to a future version of Incus with Debian 13 won’t be a problem as Incus is just a fork and stgraber and other members of the Incus/LXC projects work very closely or also work in Debian.

                  Debian users will be fine one way or the other. I specifically asked stgraber about what’s going to happen in the future and this was his answer:

                  We’ve been working pretty closely to Debian on this. I expect we’ll keep allowing Debian users of LXD 5.0.2 to interact with the image server either until trixie is released with Incus available OR a backport of Incus is made available in bookworm-backports, whichever happens first.

                  I hope this helps you decide.

              • tofubl@discuss.tchncs.de
                link
                fedilink
                English
                arrow-up
                1
                ·
                10 months ago

                Very informative, thank you.

                I am generally very comfortable with Linux, but somehow this seems intimidating.

                Although I guess I’m not using proxmox for anything other than managing VMs, network bridges and backups. Well, and for the feeling of using something that was set up by people who know what they’re doing and not hacked together by me until it worked…

                • TCB13@lemmy.world
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  10 months ago

                  I guess I’m not using proxmox for anything other than managing VMs, network bridges and backups.

                  And LXD/Incus can do that as well for you. Install it an by running incus init it will ask you a few questions and get an automated setup with networking, storage etc. all running and ready for you to create VMs/Containers.

                  What I was saying is that you can also ignore the default / automated setup and install things manually if you’ve other requirements.

                  • tofubl@discuss.tchncs.de
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    edit-2
                    10 months ago

                    Okay, I think I found a bit of a catch with Incus or LXD. I want a solution with a web UI, and while Incus has one, it seems to have access control either browser certificate based or with a central auth server. Neither are a good solution for me - I would much prefer regular user auth with the option to use an auth server at some point (but I don’t want to take all of this on all at once.)

                    I hope it’s okay that I keep coming back to you with these questions. You seem to be a strong Incus-evangelist. :)

                    I guess I could only expose the web UI on localhost and create an SSH tunnel in order to use it…? Not so good on mobile though, which is the strongest reason for a webui.

      • ikidd@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        edit-2
        10 months ago

        Proxmox is quite simple. As a former VCP, I find Proxmox more intuitive to use.

        If you need specific help with Proxmox and/or ZFS, you might also look at posting on https://www.practicalzfs.com

        And +1 for using OPNsense

      • kylian0087@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        10 months ago

        From my understanding is that Proxmox is one of the more easy platforms to learn. I must say iI never used it personally.