I Connected AI to My Proxmox Cluster Using MCP and It Was Better Than I Expected #proxmoxmcp #proxmoxai #homelab #mcpserver https://www.virtualizationhowto.com/2026/07/i-connected-ai-to-my-proxmox-cluster-using-mcp-and-it-was-better-than-i-expected/

Why I Never Update My Proxmox Cluster Without This Script Anymore. Hello fellow homelabbers, I made a mistake. As a homelab administrator, I used to think I had the perfect routine for updating my Proxmox VE hosts. I was methodical, cautious, and followed best practices. When a new kernel or patch required a reboot, I would gracefully shut down every single Virtual Machine (VM) and LXC container on the node. I would wait until they were completely offline, perform the reboot, verify everything came back up, and only then move on to the next host. I thought doing things "one by one" manually was the ultimate safety net. But I was wrong. The Update That Blindside Me During a recent maintenance window, I did exactly that. I cleanly stopped my workloads and rebooted. To my horror, my cluster lost quorum. Suddenly, VMs refused to start, configurations locked up, and I found myself staring at a broken environment. How did this happen despite my neat, manual process? While my cluster was running prior to the reboot, a background package upgrade had altered the SSH host keys on my external Qdevice host. Simultaneously, the file permissions on the NSS certificate database (/etc/corosync/qnetd) had been reset to root. Because everything was running in active RAM, the cluster looked healthy on the surface. But the second the node rebooted and tried to re-authenticate its TLS sockets and SSH keys over the network, it hit a brick wall. It was a silent failure that lay in ambush, waiting for a reboot to trigger it. That night taught me a stressful but valuable lesson: manual checks and raw command outputs aren't enough when you're managing complex cluster architectures. Why This Script is a Game-Changer To ensure I never face that blind panic again, I developed a universal pre-reboot check script. It has completely transformed how I handle cluster maintenance, and there are three reasons why it is now an indispensable tool in my environment: 1. It Eliminates Human Interpretation Error

7 Open Source Infrastructure Projects I'm Watching Closely Right Now #homelab #projects #learneveryday https://www.virtualizationhowto.com/2026/07/7-open-source-infrastructure-projects-im-watching-closely-right-now/

Hello fellow homelabbers, After recently migrating my homelab DNS infrastructure from Pi-hole to a High-Availability Technitium DNS Cluster, I wanted to share my architecture, findings, and performance testing results with the community. When designing a homelab DNS setup, you face multiple implementation choices. Because I am running my two DNS instances on significantly different generations of hardware, finding the optimal configuration required some real-world benchmarking.The Hardware & Topology. My Proxmox environment utilizes two distinct physical hosts:Lenovo ThinkStation P520 – Running an Intel Xeon W-2135 CPU (released in 2017).Aoostar WTR Pro Max – Running an AMD Ryzen 7 8845HS CPU (released in 2024).The 2024 Ryzen CPU is substantially more powerful than the 2017 Xeon. To optimize performance based on this hardware asymmetry, I configured my router's DHCP scope to lease the Aoostar instance (192.168.11.51) as the Primary DNS server, and the Lenovo instance (192.168.11.50) as the Secondary DNS server. This ensures the bulk of the network load is handled by the faster CPU, while the older hardware stands by as a seamless failover node. Both servers stay perfectly synchronized using the built-in Technitium Cluster Sync application. The Architecture: Solving the Encryption vs. Autonomy Paradox.My goal was absolute privacy inside my network, combined with complete independence from upstream public DNS providers (like Cloudflare, Google, or Quad9). Achieving this requires balancing two distinct traffic directions:Inbound (Client to Homelab): DNS-over-HTTPS (DoH)To secure local network traffic, I deployed Nginx Proxy Manager (NPM) inside my Docker environment. NPM handles the incoming HTTPS connections on port 443 using a valid Let's Encrypt Wildcard Certificate. To prevent complex Nginx database and SSL handshake issues (ERR_SSL_UNRECOGNIZED_NAME_ALERT), I kept NPM clean. I created two straightforward Proxy Hosts (dns1.patad.nl and dns2.patad.nl) that route traffic on the backend directly to the Technitium LXC containers on a custom DNS-over-HTTP port (8053).To make this accessible locally without routing traffic out to the internet, I configured a Split-Horizon DNS zone within Technitium for (my domainname), pointing dns1 and dns2 directly to NPM's local IP address.

Why I Stopped Treating Docker Containers Like Tiny Virtual Machines #docker #containers #homelab https://www.virtualizationhowto.com/2026/07/why-i-stopped-treating-docker-containers-like-tiny-virtual-machines/