One of the challenges I think that most of us have is simply keeping track of everything. It's easy to spin up a new VM, add another mini PC, connect an IoT device, or build out another VLAN. Before long you're wondering where that random IP address came from or what server is actually running a particular service. I have been there MANY times.

LAN Orangutan looks like it aims to solve that problem. Instead of just running a one-time network scan, it provides a lightweight inventory of your network with a clean web interface where discovered devices are stored and organized over time. It uses Nmap for discovery. So it definitely comes from good "stock" with its architecture for scanning.

Some of the features that caught my eye with this project includes:

• Automatic network discovery
• Multi-network scanning
• Device inventory with persistent records
• Device labels and notes
• Tailscale support
• Modern web dashboard
• CLI with JSON output
• Cross-platform support for Linux, Windows, and macOS
• Single binary deployment

The Tailscale support is especially interesting. I know quite a few of us have multiple home labs or remote sites connected with Tailscale. So this is super interesting being able to inventory devices across those networks.

I also like that the project doesn't appear to be trying to become an all-in-one monitoring platform. There are already plenty of tools in this space that can collect metrics, monitor uptime, or manage enterprise devices. LAN Orangutan is instead laser focused on that simple question of finding out "what devices are on my network?"

According to the roadmap, the developers are also planning features like scheduled scans, notifications, historical tracking, and an API, which could make it even more useful for automation and keeping home lab documentation up to date.

I'm curious how it compares with some of the other tools many of us already use, such as:

• NetBox
• NetAlertX
• LibreNMS
• Uptime Kuma
• Smokeping
• ArpWatch

LAN Orangutan looks like it could fill a nice niche as a lightweight discovery and inventory tool without bringing along a lot of additional complexity.

I'm planning to spin this up in my own lab and see how it performs across multiple VLANs and remote networks. If it works as well as it looks, I could see it becoming another useful utility to keep around alongside the rest of the home lab toolbox.

Check out the project on Github here: 291-Group/LAN-Orangutan: LAN Orangutan is a lightweight network scanner with persistent device labeling, multi-network support, and Tailscale integration. Built by 291 Group.

Has anyone here already tried it? I'd be interested to hear how well it performs and if

you've found any features that really stand out.

MINISFORUM MS-03 Workstation | Intel Core Ultra 9 386H | Fluent 35B Local LLMS – Minisforum

As most of you already know, I am currently running multiple MS-01 systems in my Proxmox cluster, and they've honestly been some of the best home lab purchases I've made. They've been rock solid, quiet, and incredibly capable for their size and have served me well now for 3 years or so (I had two original ones and bought 3 more for my Proxmox cluster). So, building on my good experiences with the MS-01, the MS-03 is very interesting.

From what I've been reading, this isn't just a CPU

refresh.

Some of the specs that stand out to me are the following:

• Intel Core Ultra 300 (Panther Lake) processor
• Support for up to 128 GB of DDR5-7200 memory
• Three M.2 NVMe slots
• PCIe x16 slot that can take a low profile GPU
• Dual USB4 ports
• 2x 10Gb SFP+ ports
• 1x 10Gb RJ45 port
• 1x 2.5Gb RJ45 port

That networking configuration is pretty crazy for a system this size. So if you are counting, that is (1) more 10 GbE connection than the MS-01 has. It has the (2) 10 gig SFP+ cages and then (2) 2.5 GbE ports. One of the things I already love about the MS-01 is not having to add external adapters just to get fast networking in the lab. So, it is great to see the MS-03 keeping with that strength and even adding to it. 

The support for a low profile PCIe GPU is still an option with the MS-03 as it has been with the MS-01. From everything I've read, it supports cards up to 75W, which opens up some interesting possibilities. Whether that's adding a small NVIDIA card for local LLMs, extra media transcoding, or just having GPU resources available inside a Proxmox host, it's nice to have the option.

I'm also glad to see support for 128 GB of RAM (althought who can afford that right now? LOL). Home lab workloads have a way of growing over time, and I don't know many people who have ever said, "I wish I had less memory." But, again, in all seriousness, this is going to be a hard number to max out in today's market.

One interesting design choice is the processor itself. Instead of going with the Panther Lake SKU that has the largest integrated GPU, Minisforum appears to have chosen the version that leaves enough PCIe lanes available for the expansion slot. Personally, for us in the home lab crowd, I think that's the right decision for a workstation or virtualization platform. I'd much rather have expansion options than a faster integrated GPU.

I'm really curious to see a teardown once these start shipping. I'm wondering things like:

• How well does it cool under sustained load? There were some cooling problems noted with the MS-A2.
• Is the fan noise similar to the MS-01?
• Are there any compromises with the PCIe slot when all three NVMe drives are populated?
• Does Proxmox detect everything cleanly out of the box?
• How much power does it draw when it's sitting idle? Power consumption is also a big characteristic for running a system 24x7x365.

At this point I don't think Minisforum has announced pricing yet, so that's probably going to be one of the biggest questions with the unit. If they can keep it somewhere in the same ballpark as the MS-01, which will be hard to say if that is possible in today's market, I think these are going to end up in a lot of home labs.

I'm definitely going to be keeping an eye on this one. Is anyone else thinking about replacing an MS-01 with one of these, or would this be your first Minisforum system? I'd be interested to hear what you would use it for.

For years, if you wanted redundant Pi-hole instances you had a few different options, which have amounted to the following

• Point clients at two different Pi-hole servers and hope devices actually fail over correctly
• Use Gravity Sync (Pi-Hole v5) or Nebula Sync (Pi-Hole v6) to keep configurations synced
• Build your own keepalived or VRRP solution for a floating virtual IP
• Write custom scripts to enable and disable DHCP when a primary server failed

It worked, but it always felt like you were stitching together several different projects to accomplish this and I think that is why so many have been interested in Technitium lately.

This new project, Pi-hole HA, looks like a great project that might be able to solve this issue a little more elegantly it looks like.

Some of the highlights include:

• Automatic configuration sync between Pi-hole nodes
• Optional DHCP failover
• Virtual IP (VIP) support so clients can continue using a single DNS address
• Health monitoring between cluster members
• Native management page directly inside the Pi-hole web interface
• Works for both DHCP users and DNS-only deployments, automatically detecting which mode you're running during installation

What really caught my attention is that this doesn't appear to rely on SSH keys or external utilities you are running somewhere. The nodes communicate over HTTP and the project uses supported Pi-hole interfaces rather than patching Pi-hole itself. According to the author, everything is contained in a fairly clean installation with an uninstall option if you decide to remove it later.

As someone who has written quite a bit about home lab DNS redundancy, this feels like a much better solution even than the traditional Gravity Sync plus keepalived setup many of us have been using.

I also like that it supports a DNS-only mode. Many of us let our routers or firewalls handle DHCP and simply want redundant DNS with synchronized blocklists and settings. The installer apparently recognizes that config setup and doesn't try to take over DHCP automatically.

I haven't had a chance to deploy this in my lab yet, but it is definitely on my list to test. If it proves to be a reliable way to configure this over time, I could see this becoming the preferred way to build highly available Pi-hole deployments in home labs.

Has anyone here already installed it? I'm especially curious about:

• How reliable the failover has been
• Whether the VIP transitions are seamless
• How well it behaves on Docker deployments
• Any issues you've run into during upgrades

For anyone interested, here's the original announcement and documentation:

https://discourse.pi-hole.net/t/release-pi-hole-ha-automatic-dhcp-failover-vip-and-config-sync-for-a-pi-hole-cluster/86667

There is also a pretty good Reddit thread where the author looks to be very responsive: Made a tool for automatic DHCP failover + config sync across multiple Pi-holes (bare-metal or Docker) : r/pihole

I'm looking forward to hearing if anyone has seen this and tested it as of yet? This looks like it could simplify one of the more common "DIY" pieces of home lab infrastructure around DNS if ones are looking to run Pi-Hole.

Brandon

Glad to have you on the forums. I think you have hit on something that all of us encounter on our journeys in our home lab environments. They start out just beginning the process of running a few self-hosted apps not really thinking about the design so much. But as our labs mature and we start thinking more critically about our designs, that is a pivot point. I know I experienced that as well. 

I know for me, I think of the various technologies as different tools and try to use the best one for the job. Usually, for me in my current rendition of my home lab, I try to run as many apps and services in containerized environments. Containers are super lightweight, fast to spin up, and easy to provide HA in a Swarm or Kubernetes setup. However, not all business-type applications are supported in a containerized setup. Larger monolithic apps usually work best in a dedicated VM with enough resources for running the app, underlying services, etc. If running containerized services though, you can definitely group things together easily as "services" in something like Swarm or namespaces with Kubernetes that helps with management and design. VMs can also be logically grouped together. You can of course create "stacks" of VMs with technologies that Proxmox and other hypervisors offer with resources, startup and shutdown ordering, tags, and other things like a common network.

Also, network connectivity and segmentation come into play with this as well. I do try to think more in terms of Web > App > Database 3 tier type application architectures with any number of microservices living at various levels of that application blueprint. Hopefully, some of these ideas help out with some of the things you are considering. Let me know what you have been leaning towards with your design. Definitely curious on that front.

Brandon

Initially it’s pretty simple, but once you start stacking multiple services, things slowly shift. It’s not just about getting stuff running anymore, you start thinking more about how everything fits together, how services interact, and how to keep things from becoming messy.

I’ve also noticed that even small business-type applications start feeling very different when they’re running in a virtualized setup instead of just a single machine. It kind of forces you to think in a more structured way.

I’ve seen a few setups where people try to simulate small internal business environments in their labs just to test how different workflows behave under different conditions. Things like HR flows, reporting, and basic automation usually come up in that kind of setup.

I came across Vertex-HCM in that context as well, more like an example of something that fits into that kind of workflow-based system rather than a standalone app.

I’m just curious how others are handling this. Do you usually keep things separated in different VMs, or do you just group services together and manage isolation another way?

What’s been more stable in your experience?

I didn’t realize tools like Ollama have made it this accessible now. The privacy angle is actually the main reason I’m considering self-hosting instead of relying on cloud APIs.

I might try a small model first on my own machine just to see how it performs in real use. Good practical guide overall.

I've run both setups over the years, and unless your primary goal is local AI, I'd put the money into RAM and storage before spending it on a dedicated GPU. Of course RAM prices are asinine! For Proxmox itself, Docker containers, and what I would call the typical self-hosted services, the GPU is basically irrelevant for the most part. Virtual machines, Kubernetes, media servers, databases, DNS, monitoring, and automation tools are all much more dependent on CPU cores, memory, and fast NVMe storage. So graphics power is nice to have, but definitely won't give you as much bang for your buck for "normal" home lab resources.

Where a dedicated GPU changes the equation is local AI. If you're planning to run modern LLMs regularly, VRAM becomes the limiting factor here as it does with dedicated discreet graphics also. Even though Intel Arc and AMD Radeon iGPUs have gotten much better, they're still sharing system memory, which is a lot slower than dedicated VRAM. They'll run smaller models, but once you start experimenting with larger models or want faster token generation, a discrete GPU makes a huge difference when it comes to those types of operations.

Personally, I'd recommend one of these paths:

• General home lab: Get a modern Ryzen or Intel mini PC, max out the RAM (64 GB or more if supported), install two fast NVMe SSDs, and you will have a really great virtualization platform you can build on
• Home lab + occasional AI: Start with the integrated GPU and see if it meets your needs in just playing around. You can always build a separate AI box later.
• Home lab + serious local AI: Buy hardware specifically for AI. Keeping your AI workload separate from your Proxmox infrastructure makes upgrades much easier I think

I also wouldn't underestimate the value of memory. Running out of RAM happens long before you'll wish you had more GPU for most home lab use cases. Extra RAM lets you run more VMs, larger Kubernetes clusters, and bigger ZFS ARC caches, all of which you'll notice every day. But again, the prices are pretty prohibitive these days. If I were starting from scratch today, I'd buy a moderately powerful mini PC with an Intel Core Ultra or AMD Ryzen AI processor, 64 to 96 GB of RAM, dual NVMe drives, and run Proxmox on it. Then, if I discovered that local LLMs became a major hobby or interest outside of tinkering, I'd add a dedicated AI machine with an NVIDIA GPU rather than trying to make one system do everything. But this is just my two cents and what works for one person may not be the right answer for another. Hopefully this helps Keegan.

Brandon

The thing is, most mini PCs with dedicated GPUs seem to come from brands like Minisforum, Geekom, and Beelink, but they add a lot of cost and power consumption. On the other hand, newer iGPUs have gotten a lot better. I'm curious whether the performance trade-off is worth the savings, especially for someone just starting out with self-hosting.

Here's what I'm wondering: Have you found that a dedicated GPU actually makes a difference for home lab workloads, or does integrated graphics handle most virtualization and containerization tasks just fine?

I'd love to hear if anyone has real-world experience or suggestions on this setup, especially if you've tried both. What about power efficiency? does a GPU-equipped mini PC draw a lot more power during idle or light loads? And if you're running local LLMs, what hardware did you settle on and why?

Also, I'm curious if anyone has experience with upgrading RAM and NVMe storage on these compact little pcs. That seems like a smarter investment than GPU power for my use case, but I want to make sure I'm not missing something important. Share your thoughts and help me make the best decision i can...

Download the VMware OVA

Download the VMware OVA from Flatcar:

https://www.flatcar.org/releases/

Choose the VMware/vSphere OVA image.

Create your Butane configuration

Create your normal Butane configuration file (example here):

variant: flatcar
version: 1.0.0

passwd:
  users:
    - name: linuxadmin
      groups:
        - sudo

Save it as:

flatcar.bu

Convert Butane to Ignition

Generate the Ignition JSON:

butane --pretty --strict flatcar.bu > flatcar.ign

Verify the file starts with JSON:

head flatcar.ign

You should see something similar to:

{
  "ignition": {
    "version": "3.3.0"
  }
}

Base64 encode the Ignition file

Encode the generated Ignition file:

base64 -w0 flatcar.ign > flatcar.ign.b64

View the contents:

cat flatcar.ign.b64

Copy the entire output.

Deploy the OVA

Deploy the Flatcar OVA in vSphere.

You can either populate the Ignition fields during deployment or add the values later as Advanced Parameters before the VM is ever powered on. But populating values manually during the OVA install is tedious and doesn't scale very well. You can leave the following screen blank during the deployment:

Configure Ignition using Advanced Parameters

This is the part that you want to pay attention to the details. You need to create the following two advanced configuration parameters:

guestinfo.ignition.config.data
guestinfo.ignition.config.data.encoding 

With the VM powered off:

VM Settings > VM Options > Advanced Parameters

Add:

Both parameters are needed. If you forget to add the base64 advanced setting for the encoding value, you will see errors when it tries to load the config, like this:

Without the encoding parameter, Flatcar will attempt to parse the base64 string as JSON and fail with errors similar to:

error at line 1 col 2: invalid character 'e'

VMware network interface naming

One difference I found out between Proxmox and VMware is interface naming.

In my environment VMware name the NIC as:

ens192

Make sure of the the interface name before building static network configuration.

Example:

Name=ens192


Address=10.1.149.20/24
Gateway=10.1.149.1
DNS=10.1.149.10
Domains=cloud.local

Be careful with Ignition file downloads

My Ignition file contained:

contents:
  source: https://extensions.flatcar.org/extensions/docker-compose.conf

and similar remote downloads.

These worked in my Proxmox deployment but failed during VMware deployment because Ignition attempted to fetch them before networking and DNS were fully available.

The symptom looked like:

lookup extensions.flatcar.org on :53

If you encounter this, deploy without the remote contents.source entries first and move those downloads to a systemd service that runs after:

network-online.target

Verify Ignition

After booting:

journalctl -u ignition-fetch-offline.service -b

or

journalctl -b | grep -i ignition

Successful processing should show:

using OVF environment from guestinfo
config successfully fetched

Hopefully, this forum post will help any who might be looking for information on how to deploy Flatcar in VMware vSphere. It is definitely doable but the process differs quite a bit from Proxmox.