Step 1: Force APT to use IPv4

If you are not using IPv6 in your environment, this keeps APT from wasting time trying broken or unreachable IPv6 paths.

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

You can make sure it "sticks" with the following:

cat /etc/apt/apt.conf.d/99force-ipv4

You should see something like this:

Acquire::ForceIPv4 "true";

Step 2: Change Ubuntu repositories from HTTP to HTTPS

This is the one that I found made the biggest difference, since it looks like it is hitting cloudflare IPs. On Ubuntu 24.04 (Noble), edit the .sources file with this:

sudo sed -i \
's|http://archive.ubuntu.com/ubuntu|https://archive.ubuntu.com/ubuntu|g;
 s|http://security.ubuntu.com/ubuntu|https://security.ubuntu.com/ubuntu|g' \
/etc/apt/sources.list.d/ubuntu.sources

Make sure of your changes.

cat /etc/apt/sources.list.d/ubuntu.sources

You should now see:

URIs: https://archive.ubuntu.com/ubuntu

and this also:

URIs: https://security.ubuntu.com/ubuntu

Step 3: Refresh APT

sudo apt clean
sudo apt update

Step 4: Test download speed

To make sure of your speed improvement, below is just an example that I used since I was trying to install JAVA:

wget -4 -O /dev/null \
https://archive.ubuntu.com/ubuntu/pool/main/o/openjdk-17/openjdk-17-jre-headless_17.0.19+10-1~24.04.2_amd64.deb

45.86 MB in 3.2 seconds
≈14.5 MB/sec

Veeam Backup & Replication v13.1 new features

• VM replication for Proxmox VE
  • Native VM replication jobs are now there for Proxmox VE.
  • Supports host-to-host replication, cross-datacenter replication, and replication across different storage types (awesome)
• Instant VM Recovery to Proxmox VE
  • Instantly recover VMs from backups created on other supported platforms directly into Proxmox VE
  • Lets workloads run immediately before migrating them to production storage
  • ***Note*** - This is listed as Experimental Support in v13.1
• VLAN tagging during restore
  • Restore and worker VMs can now be assigned VLAN tags
  • Useful if you are still using VLAN-based networking instead of Proxmox SDN
• Automatic VirtIO driver injection
  • Restoring VMs from VMware, Hyper-V, or other supported platforms into Proxmox automatically injects VirtIO drivers.
  • Better cross-platform migration
• Complete Proxmox Web UI support
  • Backup jobs
  • Restore operations
  • Infrastructure management
  • All available through the Veeam Web UI the same as VMware and Hyper-V.
• Advanced RBAC for Proxmox
  • Granular role-based permissions can be assigned to specific VMs. But also for jobs, categories, and infrastructure objects.
  • ***Note*** - This is listed as Experimental Support in v13.1
• Improved restore job statistics
  • Better restore progress reporting and visibility in the Web UI.

Other Proxmox-related improvements found in v13.1

• Universal Hypervisor API (UHAPI)
  • New framework allowing additional hypervisors to integrate with Veeam more quickly
  • Shows Veeam's continued support and development in multi-hypervisor support, which benefits Proxmox adoption
• Expanded "restore from anywhere" support
  • Many newly supported hypervisors (Citrix XenServer, XCP-ng, Sangfor aSV, Platform9, VergeOS) can restore workloads into Proxmox VE using Instant Recovery (currently Experimental)
• Web UI Instant Recovery from any platform
  • Image-level backups from supported platforms can now be restored through the Web UI, further simplifying migrations into Proxmox environments
• Cloud Connect enhancements
  • Service providers can now perform entire VM restores directly to Proxmox VE for tenant backups
• REST API additions
  • New REST API endpoints for Proxmox VE backups, restore points, sessions, infrastructure queries, and job control

Download the full "What's new" PDF from Veeam here: veeam_backup_13_1_whats_new_wn.pdf.

My takeaway

If you have been wondering if Veeam was "all in" on Proxmox, this release to me definitely seals that discussion. Veeam looks to be committed to Proxmox as a major platform and I think this will further facilitate customers getting off Broadcom and onto a platform that is reasonably priced again.

What are your thoughts? Is your organization migrating fully to Proxmox? Looking at Veeam or already a Veeam customer? I would be curious to know what you think.

docker system prune -a -f

But I still had a lot of disk space used. Pulling out the trusty WinDirStat tool that I have loaded, I started looking at the Largest Files on my machine and found that my docker_data.vhdx file was around 261 GB! 

Even after clearing up old images, the VHDX was still large. So we can use diskpart to compact the VHDX like this. First shutdown WSL and see if you have anything else running:

wsl --shutdown
wsl --list --running

Now, we use diskpart to shrink the VHDX. Launch diskpart:

diskpart

Then run the following commands, replacing the vdisk file path with the file path for your machine:

select vdisk file="C:\Users\localadmin\AppData\Local\Docker\wsl\disk\docker_data.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

Hopefully these simple steps helps someone else facing this same issue!

Brandon

Here is the GitHub: https://github.com/ffind-dev/pve-ups

If you've ever configured NUT, you know it is super powerful, but it is also known to not be for the faint of heart. It can be more complicated than what many home lab users actually need. This project takes a different approach by focusing on a graceful Proxmox shutdown during a power outage. The author was transparent that he vibe coded the tool. But honestly, it looks really amazing.

From what I've read, it runs as a lightweight Debian LXC and provides a web-based wizard to set things up instead of making you edit NUT configuration files. It communicates with Proxmox using the API. I like this as it means you don't have to install agents on each node or rely on SSH for shutdown operations.

A few features that stood out:

• Web UI for configuration
• Uses Proxmox API tokens with few permissions actually needed
• Gracefully shuts down VMs and LXCs before powering off the hosts
• Keeps the host running the appliance online until the rest of the cluster has shut down
• Very lightweight resources are needed.

One important limitation is that it currently supports UPS units with an SNMP management card only. If you're using a USB-connected UPS, NUT is still the recommended solution for that configuration..

I haven't had a chance to test this in my own lab yet, but I really like seeing projects that simplify common Proxmox management tasks. For those of us already running network-managed APC, CyberPower, or Eaton UPS units, this looks like it could be a nice alternative.

Has anyone here already tried this or looking at deploying it? If so, I'd be interested to hear:

• Which UPS are you using?
• How was the setup process?
• How has it behaved during actual power events?

Looking forward to hearing everyone's experiences.

machine:
  kubelet:
    extraConfig:
      # Start GC sooner than the default ~85%
      imageGCHighThresholdPercent: 75
      # Keep reclaiming until under this
      imageGCLowThresholdPercent: 65
      # Don't delete brand-new unused images
      imageMinimumGCAge: "2m"
      # Also drop unused images older than 7 days even if disk isn't critical
      # (this is what should eat old gitlab-ee / pulse tags)
      imageMaximumGCAge: "168h"

Apply the config patch on all nodes that have disk pressure and Talos will begin discarding old images immediately. Comparing from before I ran the patch to after:

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.

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?

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...