How to Create VLANs with MikroTik — The Proper Way (Bridge VLAN Filtering)

In a previous post I covered the easy way to create VLANs on MikroTik — one bridge per VLAN. It works, it’s great for learning, but it doesn’t scale well and it’s heavier on the CPU than it needs to be. If you haven’t read it, you can find it here.

This post covers the proper way: bridge VLAN filtering. One bridge, one VLAN table, everything in one place. Understanding the easy way first makes this much easier to appreciate — but you don’t need it to follow along.

The topology is the same as in the previous post: a MikroTik router connected to a Cisco switch via a trunk port, three VLANs, devices on each VLAN getting DHCP and internet access.


How Bridge VLAN Filtering Works

Instead of creating a separate bridge for each VLAN, we create a single bridge and enable VLAN filtering on it. The bridge then maintains a VLAN table that controls which ports carry which VLANs — tagged (trunk) or untagged (access).

The key concepts:

  • Tagged ports carry traffic for multiple VLANs with 802.1Q tags. Your uplink to a switch or another router is typically tagged.
  • Untagged ports carry traffic for a single VLAN with no tag. Your end devices (PCs, printers, APs) connect to untagged ports.
  • PVID (Port VLAN ID) is the default VLAN assigned to untagged traffic arriving on a port. When a frame arrives without a tag, the bridge stamps it with the PVID before processing it.

This model maps closely to how Cisco switches think about VLANs — trunk ports and access ports — which may feel more familiar.


Step 1 — Create the Bridge

/interface bridge
add name=bridge-vlans

We create the bridge first without enabling VLAN filtering yet. We’ll turn that on after the VLAN table is fully configured — enabling it on an empty table drops all traffic immediately.


Step 2 — Add Ports to the Bridge

Add your trunk port (uplink to the switch) and your access ports (connected to end devices).

/interface bridge port
add bridge=bridge-vlans interface=ether5 pvid=1
add bridge=bridge-vlans interface=ether2 pvid=2
add bridge=bridge-vlans interface=ether3 pvid=3
add bridge=bridge-vlans interface=ether4 pvid=4
  • ether5 is the trunk port to the Cisco switch — PVID 1 is fine here since tagged traffic will override it
  • ether2, ether3, ether4 are access ports — PVID tells the bridge which VLAN to assign untagged frames arriving on each port

Step 3 — Configure the VLAN Table

This is where you define which VLANs are allowed on which ports, and whether each port carries them tagged or untagged.

/interface bridge vlan
add bridge=bridge-vlans vlan-ids=2 tagged=ether5,bridge-vlans untagged=ether2
add bridge=bridge-vlans vlan-ids=3 tagged=ether5,bridge-vlans untagged=ether3
add bridge=bridge-vlans vlan-ids=4 tagged=ether5,bridge-vlans untagged=ether4

Breaking this down:

  • VLAN 2 is carried tagged on ether5 (the trunk to the switch) and on bridge-vlans itself (so the router can route it), and untagged on ether2 (the access port for VLAN 2 devices)
  • Same pattern for VLANs 3 and 4

Step 4 — Enable VLAN Filtering

Now that the VLAN table is in place, it’s safe to enable filtering. The bridge will start enforcing the table immediately.

/interface bridge
set bridge-vlans vlan-filtering=yes

Step 5 — Create VLAN Interfaces for Routing

To route between VLANs and assign IP addresses, we need VLAN interfaces attached to the bridge.

/interface vlan
add interface=bridge-vlans name=vlan2 vlan-id=2
add interface=bridge-vlans name=vlan3 vlan-id=3
add interface=bridge-vlans name=vlan4 vlan-id=4

Step 6 — Assign IPs, DHCP, and NAT

This part is identical to the easy way — the IP addressing, DHCP, and NAT configuration doesn’t change, only the interfaces you assign them to.

/ip address
add address=10.0.2.1/24 interface=vlan2 network=10.0.2.0
add address=10.0.3.1/24 interface=vlan3 network=10.0.3.0
add address=10.0.4.1/24 interface=vlan4 network=10.0.4.0

/ip pool
add name=dhcp_pool0 ranges=10.0.2.2-10.0.2.254
add name=dhcp_pool1 ranges=10.0.3.2-10.0.3.254
add name=dhcp_pool2 ranges=10.0.4.2-10.0.4.254

/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=vlan2 name=dhcp1
add address-pool=dhcp_pool1 disabled=no interface=vlan3 name=dhcp2
add address-pool=dhcp_pool2 disabled=no interface=vlan4 name=dhcp3

/ip dhcp-client
add disabled=no interface=ether1

/ip dhcp-server network
add address=10.0.2.0/24 dns-server=10.0.2.1 gateway=10.0.2.1
add address=10.0.3.0/24 dns-server=10.0.3.1 gateway=10.0.3.1
add address=10.0.4.0/24 dns-server=10.0.4.1 gateway=10.0.4.1

/ip dns
set allow-remote-requests=yes

/ip firewall nat
add action=masquerade chain=srcnat

Easy Way vs. Proper Way — At a Glance

Easy WayBridge VLAN Filtering
Bridges neededOne per VLAN + one trunkOne total
Interface list sizeGrows fastClean and minimal
Adding a new VLAN3+ commands, new bridge2 commands
CPU usageHigher (software per bridge)Lower (single bridge path)
Switch chip offloadNoYes (on supported hardware)
TroubleshootingMultiple bridges to checkOne VLAN table to check
Good for learningAfter you know the basics
Good for production

A Few Things Worth Knowing

PVID must match the VLAN table. If a port’s PVID doesn’t have a corresponding untagged entry in the VLAN table, untagged frames arriving on that port will be dropped. Double-check both match — it’s the most common source of “why isn’t this device getting an IP” confusion.

The bridge itself must be tagged in the VLAN table for routing to work. That’s what the bridge-vlans entries in Step 3 are for. If you forget this, inter-VLAN routing fails silently — devices get DHCP but can’t reach other VLANs or the internet.

This configuration assumes a clean slate. If you’re adapting this to an existing bridge that already has ports and traffic, take care — enabling VLAN filtering mid-session will drop everything that isn’t covered by the VLAN table. Test in a lab or during a maintenance window.


Final Thoughts

Once you’ve done it a few times, bridge VLAN filtering is actually simpler to manage than the easy way — there’s just less of everything. The learning curve is the VLAN table concept, which takes a bit of getting used to if you’re new to it.

If Part 1 got your VLANs working and you understand why each piece is there, you’re ready for this. The configuration is a bit more deliberate, but the payoff in cleanliness and efficiency is worth it.

Why You Should Be Running a Homelab

It’s not just a hobby. It’s the best IT training program money can’t buy.


If you work in IT, or you’re thinking about getting into it, someone has probably told you to “get a homelab.” Maybe you nodded and moved on, thinking it sounded like a lot of effort for something you’d use twice. I get it. But I’m here to make the case that a homelab is one of the most valuable things you can invest in — not just for learning, but for your career, your wallet, and your daily life at home.

I’ve been running mine for years. It started small and has grown into a three-node Proxmox cluster, a full self-hosted services stack, a home NVR system, and the foundation for a serious side income. None of that happened overnight, but all of it started with the same thing: a spare machine and a willingness to break things.

And you don’t need to start big. A Lenovo mini PC or an HP EliteDesk — 8th generation or newer — can be found used for very little money. They’re compact, power-efficient, and more than capable of running a real homelab. One of those machines, set up properly, will put you on a path of professional growth that no certification alone can replicate.

Here’s why you should do the same.


You Learn by Breaking Things, Not Reading About Them

There is no certification, no course, and no amount of documentation that teaches you the way a 2am crash does.

When my backup script left a stale NFS mount that froze an entire server for 76 minutes, I learned more about how the Linux kernel handles NFS retries than I ever would have from a book. When my network card started crashing overnight and I discovered that ICMP keeps responding even during a TX queue hang — completely defeating ping-based monitoring — that’s the kind of nuance that only comes from real experience.

But it goes well beyond server crashes. Running a homelab naturally pulls you into territory you wouldn’t otherwise explore:

  • You start setting up a firewall and end up understanding stateful packet inspection, connection tracking, and why rule order matters.
  • You want remote access, so you run your own VPN server — and suddenly WireGuard, certificates, and key management aren’t abstract concepts anymore.
  • You have IoT devices you don’t fully trust, so you learn about VLANs and network segmentation to keep them isolated from the rest of your network.
  • You deploy a few services and realize you need proper DNS — and then you’re deep into split-horizon DNS, local resolvers, and why you should never rely on your ISP’s nameservers.
  • You want HTTPS on your internal services, so you learn about TLS certificates, Let’s Encrypt, DNS challenges, and wildcard certs.
  • You spend enough time in the terminal that Linux stops being intimidating — and one day you realize you’ve made the switch from Windows entirely, not because you forced it, but because it just started making more sense.

Every failure in a homelab is a controlled failure. Nothing is on fire. No customer is affected. No boss is watching. You have the freedom to dig deep, understand what actually went wrong, and fix it properly. That knowledge sticks in a way that reading never does.


It Directly Benefits Your Career

I’m not going to name my employer, but I’ll tell you this: the skills I’ve built in my homelab have made me measurably better at my job. Troubleshooting approaches, understanding how systems fail, knowing what questions to ask — all of it comes from hours spent in my own environment where I had no one to call and no escalation path.

The homelab is also where I stay sharp on technologies I don’t use daily at work. Kubernetes, Ansible, DNS architecture, reverse proxies, certificate management — I can speak to all of these because I’ve actually run them, broken them, and fixed them.

If you’re preparing for a job interview or a certification, there’s no substitute. Talking through a lab scenario you actually built is infinitely more convincing than reciting theory. Recruiters and technical interviewers can tell the difference immediately.


It Creates Real Economic Value

This one surprises people, but the skills you develop in a homelab are directly marketable — and I’ve seen it happen firsthand with people I know.

Friends of mine who run homelabs have turned that knowledge into a genuine edge when working with small businesses and SMEs. Instead of recommending expensive proprietary solutions, they can deploy cost-effective, FOSS-based infrastructure that does the same job — sometimes better — at a fraction of the cost. A proper Proxmox cluster, self-hosted DNS, a WireGuard VPN, a mail stack, a reverse proxy with proper TLS — all of this can be set up and maintained by someone with homelab experience, and smaller clients who can’t afford enterprise vendors are hungry for exactly that.

The homelab is where you build the muscle memory to do this confidently. You’ve already broken and fixed these things in your own environment. When a client’s server goes down at an inconvenient hour, you’re not googling basic commands — you’ve been there before.

It also flattens the playing field. A freelancer or small IT consultancy with deep FOSS knowledge and homelab-built skills can compete with providers that charge ten times as much, simply by doing more with less. That’s a real business advantage, and it starts at home.


You Take Back Control of Your Data

Every service you self-host is a service you’re no longer depending on someone else to run, someone else’s servers to store your data on, and someone else’s pricing to change on you.

I run my own media server, my own photo library, my own document storage, my own password manager, my own DNS with ad-blocking, my own NVR for home cameras. None of these depend on a subscription. None of them will disappear because a company decided to shut down or pivot. None of them are sending my family’s data to a third party.

That’s not paranoia — it’s just a reasonable preference for owning the things you use every day.


Home Automation Gets Genuinely Useful

A homelab gives you the infrastructure to run Home Assistant properly — not the dumbed-down cloud version, but a real local instance with full control. When you combine that with the rest of your stack, things get interesting.

My Home Assistant is aware of everything on my network. It manages my UPS systems, monitors my servers, sends me alerts when something goes offline, and can automatically restart services when they misbehave. When my NVR node was crashing, Home Assistant detected the ping loss and cut and restored power via a smart plug to bring it back — automatically, at 3am, without me touching anything.

But what makes Home Assistant particularly powerful is that it speaks the language of virtually every smart home vendor out there. Zigbee devices, Z-Wave, MQTT, Tuya, Google, Apple, IKEA, Sonoff, Shelly — it doesn’t matter who made it, Home Assistant can integrate it. That means you’re not locked into a single ecosystem, you’re not dependent on any vendor’s cloud staying alive, and you can mix and match whatever hardware makes sense for your budget.

The automation side has real, measurable impact too. Lights that turn off when no one is in the room, climate control that adjusts based on presence, appliances that only run during off-peak hours — these aren’t just conveniences, they add up to meaningful savings on your electricity bill over time. You build them yourself, you understand exactly how they work, and you can tune them to your household’s actual patterns rather than relying on whatever a vendor’s app decides is “smart.”

And like everything else in the homelab, Home Assistant is a marketable skill. Small businesses, restaurants, offices — anyone with smart devices and no IT support has a problem you can solve. Setting up and managing a local Home Assistant instance, integrating their existing hardware, building automations that actually work reliably — that’s a service people will pay for, and it’s something you learn by running it at home first.

That’s not magic. It’s what happens when you have a proper homelab and take the time to connect the pieces.


The Cost Is Lower Than You Think

You do not need a server rack and enterprise hardware to start. The most useful nodes in my homelab are HP mini PCs that cost under $100 used. They’re compact, quiet, energy-efficient, and more than capable of running a handful of VMs or containers.

The honest costs are: hardware (low, buy used), electricity (low, small machines sip power), and time (the real investment). The time pays back in skills, income potential, and services you’d otherwise be paying subscriptions for.

Start with one machine. Install Proxmox or just plain Debian. Run one service. Break it. Fix it. Add another. That’s the entire playbook.


Where to Start

If you’re new to this, the barrier is lower than ever:

  • Proxmox VE is free, installs on almost any x86 machine, and gives you a full hypervisor with a web UI. It’s where most serious homelabs begin.
  • Old mini PCs (HP EliteDesk, Dell OptiPlex, Lenovo ThinkCentre) are ideal starter hardware — small, cheap, low power.
  • Self-hosted services worth starting with: a DNS filter for ad-blocking, a reverse proxy for clean HTTPS access to your services, a self-hosted password manager, and a file sync solution.
  • The community around homelabs is genuinely helpful — Reddit’s r/homelab and r/selfhosted are full of people at every level. YouTube is also an incredible resource: channels like Christian Lempa, Techno Tim, DBTech, and Craft Computing cover everything from beginner setups to advanced configurations, all with real demos and honest explanations.
  • AI as your co-pilot — this is something I didn’t have when I started, and it changes the game completely. Before deploying anything, you can describe your idea to your AI of choice, walk through the architecture, catch the gotchas before they bite you, and get a second opinion on your approach. You’re not starting alone anymore. You can go from “I want to do X” to a working plan in minutes, then learn deeply as you actually build it.

The most important thing is to start. Don’t wait until you have the perfect hardware or the perfect plan. Stand something up, see what breaks, and go from there. The learning is in the doing.


The Honest Part

A homelab is not always fun. There are nights where something breaks at the wrong time, a service goes down that your household depends on, or a fix you were sure would work makes things worse. That’s part of it.

But those moments are also exactly why the homelab works as a learning environment. You’re motivated to fix it because you built it and you care about it. That motivation is the engine behind everything else.

I used to be a gamer. I still play occasionally — maybe five times a year — and I have nothing against it. But somewhere along the way I found that homelabing is more satisfying and enjoyable, honestly. There’s something about having fun while actually learning that hits differently. Every problem you solve, every service you deploy, every crash you diagnose and fix — it’s leveling up in real life. You’re not accumulating points in a game world, you’re accumulating skills and knowledge that carry over into everything you do professionally. That feeling is genuinely hard to replicate.

And then something interesting happens: you start sharing your services with friends and family. You give someone access to your media server, or set up your parents with a VPN, or share your media library with a relative. Without realizing it, you’ve become their service provider.

If what you provide is good, they’ll rely on it. And if they rely on it, they’ll complain when it breaks. That’s not a bad thing — it’s actually one of the best things that can happen to you. Suddenly you’re dealing with real users, real expectations, and real consequences for downtime. You start thinking about reliability, about backups, about graceful failure. You start solving problems that mirror exactly what happens in a professional environment, but in a context where the stakes are manageable and you have full control.

That combination — low stakes, real consequences, full ownership — is what makes a homelab irreplaceable as a learning environment. If you’ve been on the fence, consider this your push. Start small, break things, learn from it, and build something that’s genuinely yours.

Come to think about it, it is kind of fun.


The author runs a three-node Proxmox homelab in Panama, self-hosts most of his daily services, and has been building and breaking things at home for years.

Frigate NVR on an HP EliteDesk G3 Mini with an i5-6500: Crashes, Workarounds, and an Unexpected Fix

How migrating from Linux Mint to headless Proxmox accidentally solved a problem I thought was unsolvable


If you run Frigate NVR on older Intel hardware, you may have noticed that “working” and “stable” are two very different things. This is the story of how an HP EliteDesk Mini G3 with an i5-6500 (Skylake) went from crashing multiple times a day to running for days without incident — and why I can’t fully explain why.


The Setup

The goal was simple: a dedicated, low-power NVR box for Frigate with five cameras, hardware-accelerated decoding via Intel VAAPI, and the OpenVINO detector for object detection. The hardware was an HP EliteDesk Mini G3 — compact, fanless, sips power. The original OS was Linux Mint, kept around from a previous life as a desktop machine.

Frigate ran in a Docker container directly on Linux Mint — no virtualization layer, just Docker on a desktop OS. VAAPI worked. Detection worked. The preview timeline ribbon worked. Everything looked fine — until the crashes started.


The Problem: i915 Instability Under Load

The Skylake iGPU (Intel HD 530) has a known relationship with the i915 kernel driver that ranges from “fine” to “spectacular failure” depending on workload, kernel version, and what feels like the phase of the moon.

Under sustained VAAPI decode load — which is exactly what Frigate does, continuously, for every camera stream — the i915 driver on Skylake is prone to GPU hangs. The symptoms look like this in the kernel log:

i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:85dffffb
i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0

After a hang, the driver attempts a GPU reset. Sometimes it recovers. Often it doesn’t — and when it doesn’t, Frigate loses its decoder, Docker becomes unresponsive, and eventually the entire node needs a reboot.

At its worst, the box was crashing every few hours. Uptime above 12 hours was rare.


Living With It: The Workarounds on Linux Mint

With the crashes confirmed as an i915 problem under sustained VAAPI load, the options on Linux Mint were limited.

Reducing detection frames: Lowering the number of frames Frigate passed to the GPU for detection (down to 2) helped reduce the frequency of hangs. It didn’t eliminate them, but it bought more time between crashes. This setting was carried over to the Proxmox setup and is still in place today. Not a fix — just turning down the pressure on a leaking pipe.

The HA watchdog: The real mitigation was a Home Assistant automation. Since the entire node would become unresponsive — not just Frigate — I set up a ping monitor in Home Assistant that continuously checked whether the box was reachable. When it stopped responding, an automation would cut power via a smart plug and turn it back on. The box would reboot, Frigate would come back up, and the cameras would be live again within a few minutes.

But here’s the part that made this setup genuinely frustrating: opening the Frigate web UI to actually watch the cameras would trigger a crash after a few minutes. When you open the live view, Frigate starts encoding additional frames to serve the stream — that extra GPU encode load was enough to push the i915 driver over the edge. The system that was supposed to let me monitor my home would reliably crash within minutes of me trying to use it for exactly that purpose. The watchdog would kick in, the box would reboot, and I’d be back to square one.

That’s not a workaround. That’s a system that works only when nobody is looking at it.


The Unexpected Fix: Remove the Desktop

The original setup was Linux Mint installed on an SSD, with Frigate recording to an external USB hard drive. It worked, but it was a general-purpose desktop OS running a 24/7 surveillance workload — with a display manager, compositor, and GUI login screen all sitting idle, consuming resources and sharing the i915 driver with Frigate.

The real reason to move to Proxmox was operational: cluster membership for centralized management and backups. The plan was always to wipe Linux Mint and install headless Proxmox regardless of whether it helped Frigate. The stability improvement was not the goal — it was a side effect.

After the migration:

  • Linux Mint replaced with bare Proxmox 9, no desktop environment, installed on the NVMe
  • Frigate moved from Docker-on-Mint into a privileged LXC (Debian 13 minimal), with Docker still running inside it
  • LXC root disk on the SSD, /dev/dri/renderD128 passed through for VAAPI
  • External HDD mounted on the Proxmox host, path bind-mounted into the LXC for recordings
  • Same Frigate config, same cameras, same OpenVINO detector
  • HA watchdog kept in place as a safety net

Uptime went from under 12 hours to multiple days. Then a week. As far as I can tell, the watchdog hasn’t fired once since.


Why Did It Work? (I’m Not Sure)

Here’s where I have to be honest: I can’t definitively explain the improvement. A few theories:

The compositor theory. Linux Mint’s desktop compositor (Muffin) was actively using the iGPU for display rendering, even with no monitor connected. Removing it likely gave the i915 driver a much quieter workload outside of Frigate’s decode jobs — and the GPU does seem to be working noticeably less hard now. Less driver state to manage, fewer context switches, less contention. This feels like the most plausible explanation, but it’s still a guess.

There’s also circumstantial evidence that supports it: while Frigate was running on Linux Mint, the desktop itself became basically unusable — sluggish, unstable, barely responsive. The box was supposed to be headless at that point anyway, but the fact that the whole desktop environment degraded under Frigate’s load suggests the GPU was genuinely being overworked — pulled in two directions at once.

The kernel theory. Linux Mint ships a recent upstream kernel. Proxmox ships a more conservatively patched kernel tuned for server workloads. It’s possible the Proxmox kernel has better i915 scheduling or fewer regressions on Skylake specifically.

The “just less stuff running” theory. A minimal headless Proxmox install has dramatically less userspace touching the GPU than a full desktop OS. Fewer background processes, no screensaver, no hardware acceleration in a browser nobody’s using.

The “it was always going to be fine, I just didn’t know” theory. Maybe the instability was already improving and the timing was coincidental.

I genuinely don’t know which of these is the real answer — or whether it’s all of them together.

In hindsight, maybe I should have known better than to provision Frigate on a desktop OS in the first place. And maybe I should have anticipated that something as GPU-heavy as continuous VAAPI decode across five camera streams wasn’t a great fit for hardware that was already doing double duty as a daily driver. But I love Linux Mint — it’s still my daily driver on my main machine — and at the time it was the path of least resistance. Sometimes you learn the hard way.


Current State

The box has been running stable since the migration. The HA watchdog is still configured because there’s no reason to remove it, but as far as I can tell it hasn’t fired once since the migration.

Frigate performs exactly as it did before: VAAPI hardware decode for all five streams, OpenVINO for object detection, the preview timeline ribbon intact. The user experience is unchanged. The operational experience is dramatically better.


What I’d Love to Know

If you’ve run Frigate (or any VAAPI workload) on Skylake hardware and have dug deeper into the i915 instability, I’d genuinely like to hear what you found. Specifically:

  • Did removing a desktop environment make a difference in your case?
  • Have you found specific kernel parameters or i915 module options that improve stability under sustained decode load?
  • Is there a known-good kernel version for Skylake + VAAPI that I should be pinned to?

The crash is gone for now. But “gone” and “understood” aren’t the same thing — and the next person to hit this problem deserves a better answer than “try running it headless and see what happens.”


Hardware: HP EliteDesk Mini G3, Intel i5-6500 (Skylake), Intel HD 530. Running Proxmox VE 9 with a privileged Debian 13 LXC, Frigate via Docker, VAAPI via /dev/dri/renderD128 passthrough.

Building a Proxmox Home Cluster Without Shared Storage, HA, or Quorum Worries

A practical guide to clustering heterogeneous homelab nodes the right way


If you’ve been running multiple Proxmox nodes as independent standalone hosts and decided to bring them together into a single cluster, you probably hit the same wall I did: most of the clustering documentation assumes you have enterprise-grade shared storage, fencing devices, and a dedicated cluster network. In a homelab, you have none of that — and if you proceed naively, you end up with a cluster that’s more fragile than your original standalone setup.

This post documents the challenges I faced when clustering three heterogeneous nodes and how I solved each one.


The Setup

Three nodes, all running Proxmox VE 9, each with its own local storage:

  • A lightweight mini PC running 24/7, designated as cluster master
  • A heavier compute node with more RAM and storage, used for demanding workloads
  • A third mini PC running a specific NVR workload

None of the nodes share a storage pool. Each has its own NVMe SSDs, HDDs, and LVM-thin pools. No SAN, no Ceph, no NFS for VM disk storage — just local disks.

The goal was simple: a single Proxmox UI to manage everything, with each node remaining fully independent and capable of booting its VMs regardless of whether the other nodes were reachable.


Challenge 1: Hostname and DNS Consistency

Before even thinking about pvecm create, Proxmox requires that all nodes can resolve each other by FQDN. Corosync and the cluster filesystem (pmxcfs) depend on it.

In my case, two nodes had their search domain set to local.homelab.net while the third was still on the old homelab.net. The result: hostname --fqdn returned different domains across nodes, which would cause cluster communication issues down the line.

The fix: Standardize all nodes to the same search domain before touching anything cluster-related. On Proxmox, don’t edit /etc/resolv.conf directly — it can be overwritten. Use the PVE API instead:

pvesh set /nodes/<nodename>/dns --search local.homelab.net

Verify with:

hostname --fqdn

All three nodes should return <nodename>.local.homelab.net before proceeding.


Challenge 2: The Quorum Problem for Standalone Nodes

This is the big one, and it catches most homelab admins off guard.

Proxmox clusters use Corosync for node heartbeating and quorum to determine cluster health. The default behavior: if a node loses quorum (can’t reach enough peers), Proxmox freezes VM operations on that node. It won’t start VMs, it won’t stop them gracefully — everything just hangs.

Quorum fencing exists for a good reason in enterprise environments: if two nodes can both write to the same shared disk simultaneously, you get catastrophic data corruption. Quorum prevents this by shutting down the “minority” side.

But here’s the thing — if you have no shared storage, there is no shared disk to corrupt. Each node only touches its own local disks. Quorum fencing in this scenario provides zero protection and causes real pain: if your cluster master goes offline for maintenance, your other two nodes refuse to start VMs until it comes back.

The fix: Set no_quorum_policy: ignore in Corosync configuration. This tells the cluster to keep running VM operations even when quorum is lost.

After creating the cluster, edit /etc/pve/corosync.conf and add it to the quorum section:

quorum {
  provider: corosync_votequorum
  expected_votes: 3
  no_quorum_policy: ignore
}

With this in place, each node operates independently even if its peers are unreachable. You get the unified management UI when everything is up, and you get resilience when things are down.


Challenge 3: Ghost Disks — The Silent Disaster

When nodes join a cluster, Proxmox replicates storage.cfg cluster-wide. This means every node suddenly “sees” the storage pools defined on all other nodes — including local LVM-thin pools that physically only exist on one machine.

The result: a node will happily display another node’s local storage as “available,” and if you accidentally provision a VM disk there, it will fail silently or corrupt. Even worse, Proxmox’s UI won’t clearly warn you that you’re trying to use storage that doesn’t exist locally.

This is the ghost disk problem.

The fix: Use the nodes= directive in storage.cfg to restrict each storage pool to only the node it physically lives on.

Example storage.cfg:

lvmthin: fast-nvme
    thinpool fast-nvme
    vgname fast-nvme
    content rootdir,images
    nodes node1

lvmthin: secondary-ssd
    thinpool secondary-ssd
    vgname secondary-ssd
    content rootdir,images
    nodes node2

lvmthin: nvr-storage
    thinpool nvr-storage
    vgname nvr-storage
    content rootdir,images
    nodes node3

The nodes= line means that storage only appears in the UI when you’re looking at the correct node. No cross-contamination, no ghost disks.

Important: storage.cfg is cluster-wide and lives in /etc/pve/. Any node can modify it, but changes replicate everywhere. Edit it once after all nodes have joined — not before, because a node join overwrites the local storage.cfg with the master’s copy.


Challenge 4: VMs Vanish From the UI After Joining

Storage was fixed, the cluster was up, all three nodes were showing green. Then I noticed something alarming: the VMs and containers on two of the three nodes had completely disappeared from the Proxmox web UI — not stopped, not errored, just gone. No entries at all under those nodes.

To be clear about what “disappeared” means here: the VMs were still running. Every service was reachable, every SSH session connected, every workload humming along normally. The problem was purely at the management layer — Proxmox itself had lost track that those VMs existed. You couldn’t start, stop, snapshot, or manage them through the UI or API. They were invisible to the cluster, but alive on the metal.

What happened: When a standalone node joins a cluster, Proxmox transitions its local filesystem to pmxcfs — the distributed cluster filesystem. As part of this transition, VM and container configuration files need to be migrated from the old standalone path into the new cluster-aware path at /etc/pve/nodes/<nodename>/qemu-server/. In my case, that migration silently failed on two of the three nodes. The config files weren’t in the old path, weren’t in the new path — they were nowhere on the live filesystem.

Checking both locations confirmed the worst:

ls /etc/pve/nodes/<nodename>/qemu-server/   # empty
ls /etc/pve/qemu-server/                    # empty

Where the configs actually were: Before completing the join, Proxmox automatically creates a compressed SQLite backup of the node’s cluster database at /var/lib/pve-cluster/backup/. The configs were in there — they just never made it out into the live filesystem.

The recovery process: extract the backup into a temporary SQLite database, query it for the config files, and write them directly into the correct cluster path.

# Load the backup into a temporary database
zcat /var/lib/pve-cluster/backup/config-<timestamp>.sql.gz | sqlite3 /tmp/node-restore.db

# Inspect the schema — it uses 'name', not 'path'
sqlite3 /tmp/node-restore.db "SELECT name FROM tree WHERE name LIKE '%.conf';"

# Restore each VM config to its correct cluster path
for vmid in 100 102 103 105; do
  sqlite3 /tmp/node-restore.db \
    "SELECT data FROM tree WHERE name='${vmid}.conf';" \
    > /etc/pve/nodes/<nodename>/qemu-server/${vmid}.conf
done

# For LXC containers, the path differs
for ctid in 300 301; do
  sqlite3 /tmp/node-restore.db \
    "SELECT data FROM tree WHERE name='${ctid}.conf';" \
    > /etc/pve/nodes/<nodename>/lxc/${ctid}.conf
done

After writing the configs, the VMs reappeared in the UI immediately — no restart required. pmxcfs picks up new files in real time.

The lesson: If VMs disappear from the UI after a node joins the cluster, don’t panic and don’t touch the running workloads. The data and the disks are fine. The configs are almost certainly in the SQLite backup. Check /var/lib/pve-cluster/backup/ first.


Challenge 5: Why I Deliberately Skipped HA

Proxmox’s High Availability feature is prominently visible in the UI, and it’s tempting to think “I have a cluster now, I should enable HA on my important VMs.” Resist this.

HA in Proxmox works by detecting that a node has gone offline and automatically restarting its VMs on a surviving node. This requires two things that a local-storage homelab doesn’t have: shared storage (so the surviving node can actually access the VM’s disk) and a fencing mechanism (a way to guarantee the original node is truly dead before another node starts the same VM, preventing two nodes from writing to the same disk simultaneously).

Without both of these, enabling HA causes more problems than it solves. If a node goes offline, the cluster will repeatedly attempt to migrate and restart the VM on another node — and repeatedly fail, because the disk isn’t there. The cluster enters a retry loop, the VM ends up in an undefined state, and you’re left untangling it manually.

The deliberate choice here is to simply not use HA at all. The cluster serves a different purpose in this setup: unified management, a single web UI, and consolidated monitoring. Each node is responsible for its own VMs. If a node goes down, its VMs go down with it — intentionally and cleanly, with no cluster intervention. That’s fine for a homelab. You know where your VMs live, you know how to bring them back, and you don’t need the cluster to second-guess you.


The Order of Operations

Getting the sequence right matters. Here’s what worked:

  1. Fix hostnames and DNS on all nodes first
  2. Back up each node’s storage.cfg before touching anything
  3. Rename/fix any storage pools that have naming conflicts between nodes
  4. Create the cluster on the master node (pvecm create)
  5. Immediately set no_quorum_policy: ignore in corosync.conf
  6. Join remaining nodes one at a time (pvecm add --force)
  7. After all nodes have joined, edit storage.cfg once to add nodes= restrictions to every local storage pool
  8. Verify in the UI that each node only shows its own storage
  9. If VMs are missing from the UI, recover configs from /var/lib/pve-cluster/backup/ — don’t touch the running workloads

End Result

After working through all of this, the outcome is exactly what a homelab cluster should be: a single pane of glass for managing all your nodes, with each one remaining fully autonomous. Any node can go down for maintenance, upgrades, or power savings without affecting the others. The UI shows everything in one place when nodes are reachable, and gracefully marks them offline when they’re not.

No shared storage required. No HA complexity. No quorum anxiety.

If your homelab nodes are heterogeneous machines with local-only storage, this approach is the right one — just make sure you address the gotchas before you start, not after.


Running Proxmox VE 9.x across all nodes. Commands and behavior may vary slightly on older versions.