this post was submitted on 06 Feb 2025
43 points (95.7% liked)

Selfhosted

41875 readers
564 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

I'm thinking about moving my router to be a VM on a server in my homelab. Anyone have any experience to share about this? Any downsides I haven't thought of?

Backstory: My current pfSense router box can't keep up with my new fibre speeds because PPPOE is single threaded on FreeBSD, so as a test, I installed OpenWRT in a VM on a server I have and using VLANs, got it to act as a router for my network. I was able to validate it can keep up with the fibre speeds, so all good there. While shopping for a new routerboard, I was thinking about minimizing power and heat, and it made me realize that maybe I should just keep the router virtualized permanently. The physical server is already on a big UPS, so I could keep it running in a power outage.

I only have 1 gbps fibre and a single GbE port on the server, but I could buff the LAN ports if needed.

Any downsides to keeping your router as a VM over having dedicated hardware for it?

you are viewing a single comment's thread
view the rest of the comments
[–] GameGod 2 points 14 hours ago (5 children)

That is pretty sweet. I have a second server I could use for an HA configuration of the router VM. I've been meaning to play around with live migrations (KVM) so this could be a cool use case for testing.

[–] [email protected] 2 points 14 hours ago (4 children)

It works well. I have my docker hosts on HA as well because they're almost as important as the router.

If you just use 2 nodes, you will need a q-device to make quorum if you have one of the nodes down. I have the tiebreaker running on my Proxmox Backup Server shitbox I3.

Proxmox is basically just debian with KVM and a better virt-manager. And it deals with ZFS natively so you can build zpools, which is pretty much necessary if you want snapshotting and replication, which are necessary for HA.

[–] GameGod 2 points 14 hours ago (3 children)

If you just use 2 nodes, you will need a q-device to make quorum if you have one of the nodes down

I could just use VRRP / keepalived instead, no?

I should try Proxmox, thanks for the suggestion. I set up ZFS recently on my NAS and I regret not learning it earlier. I can see how the snapshotting would make managing VMs easier!

[–] [email protected] 2 points 13 hours ago (1 children)

Proxmox uses a voting system to keep cluster integrity.

Check it out, it's free and does a lot of things out of the box that take a lot of manual work otherwise. And the backup server is stellar. It does take a while to wrap your head around the whole way it does things, but it's really powerful if you spend the time to deep dive it.

[–] [email protected] 2 points 13 hours ago (1 children)

So 3+ hosts for clustering or 2 hosts and an qdevice to fake it

[–] [email protected] 1 points 3 hours ago

Yes. You can just get by with 2 devices but you need to set expected_votes=1 in the cluster config somewhere, don't recall where, and I've encountered issues with stability with that solution, seems like it'll get undone though I haven't used it for years to say if that's still the case.

The q-device will work on anything Linux that's available when the second node is down. Not having the tie-breaker isn't the end of the world, it just means you have to go in after you bring up the second node and start some things manually, and if you're replacing nodes in a 2-node cluster, it's much nicer to have the q-device.

load more comments (1 replies)
load more comments (1 replies)
load more comments (1 replies)