Date: April 30, 2026 | Tags: homelab, NAS, NFS, QNAP, Ollama, OpenWebUI, Proxmox, Docker

Summary

Successfully completed the migration of both Ollama model data and OpenWebUI application data from local VM storage to a QNAP NAS (TS-453D) via NFS. This involved diagnosing and fixing a broken NAS mount configuration, correcting NFS export issues on the QNAP, and performing live data migrations with minimal downtime.

Background

The Ollama AI stack (Ollama + Open WebUI) runs on VM 205 (IP: 10.10.20.39) inside a Proxmox VE cluster (host IP: 10.10.20.252). The stack was originally configured to store both model weights and OpenWebUI application data on a NAS via NFS mounts, but at some point the NAS mounts broke, causing the stack to fail. A previous workaround switched the Docker volumes to local paths to restore service, but the goal was always to move the data back to the NAS for centralized storage and backup.

Phase 1: NAS Mount Investigation & Diagnosis

The Problem

The NFS mounts on VM 205 were broken. The original /etc/fstab had:

10.10.20.6:/volume1/ollama-models  /mnt/nas/ollama-models  nfs defaults,_netdev,nofail,x-systemd.automount 0 0
10.10.20.6:/volume1/openwebui-data /mnt/nas/openwebui-data nfs defaults,_netdev,nofail,x-systemd.automount 0 0

Root Cause Analysis

Two distinct issues were found:

1. Wrong NAS IP in fstab: The fstab pointed to 10.10.20.6, but the actual NAS IP is 10.10.20.4. Pinging 10.10.20.6 returned 100% packet loss. Pinging 10.10.20.4 succeeded with <1ms latency.
2. Wrong path format: The fstab used Synology-style paths (/volume1/...) but the NAS is a QNAP TS-453D running QTS 5.2.3. QNAP uses different NFS export paths.

NAS Discovery

Open Ports on NAS

NFS Export Issue

Even though the NFS service was running (confirmed via rpcinfo showing NFS v2/3/4 on TCP/UDP port 2049), showmount -e 10.10.20.4 returned an empty export list. SSH into the QNAP revealed the /etc/exports file contained an invalid NFS option read-wr instead of rw, causing exportfs to silently fail with no active exports.

Phase 2: NFS Export Fix

1. SSH into QNAP NAS: ssh jczaldivar@10.10.20.4
2. Backup original exports: sudo cp /etc/exports /etc/exports.bak
3. Write corrected exports file with proper rw options (replacing invalid read-wr)
4. Reload NFS exports: sudo exportfs -ra
5. Verify exports active: sudo exportfs -v confirmed both shares exported with rw
6. Verify from Proxmox: showmount -e 10.10.20.4 now listed both /ollama-models and /openwebui-data

Corrected /etc/exports on QNAP:

/share/CACHEDEV1_DATA/ollama-models *(rw,async,no_subtree_check,no_root_squash,insecure) 10.10.20.0/24(rw,async,no_subtree_check,no_root_squash,insecure)
/share/CACHEDEV1_DATA/openwebui-data *(rw,async,no_subtree_check,no_root_squash,insecure) 10.10.20.0/24(rw,async,no_subtree_check,no_root_squash,insecure)

Phase 3: Ollama Models Migration

The NAS already contained a full set of Ollama models from a previous configuration (9.8 GB):

The NFS share was mounted on VM 205 at /mnt/nas/ollama-models, docker-compose.yml was updated to use the NAS path, and the container was recreated, immediately picking up all 4 models from the NAS.

Phase 4: OpenWebUI Data Migration

1. Mounted NFS share: mount -t nfs 10.10.20.4:/openwebui-data /mnt/nas/openwebui-data
2. Stopped open-webui container for data consistency
3. Rsync’d local data to NAS: rsync -av --delete – transferred 934 MB at ~110 MB/sec
4. Updated docker-compose.yml volume to NAS path
5. Updated /etc/fstab with correct NAS IP (10.10.20.4) and paths
6. Restarted all containers – both recreated with NAS mounts and running healthy

Verification Results

Current Network Topology

Infrastructure Overview

All devices are on the 10.10.20.0/24 subnet.

Network Connectivity Map

NAS Storage Layout

Data Flow

Request path: User Browser -> HTTP:3000 -> Open WebUI (VM 205 container) -> HTTP:11434 (docker network) -> Ollama (VM 205 container) -> GPU Inference (NVIDIA passthrough)

Storage path: Ollama reads/writes model data from /root/.ollama inside the container, which maps to /mnt/nas/ollama-models on VM 205, which is an NFS mount to 10.10.20.4:/ollama-models on the QNAP NAS (internal path: /share/CACHEDEV1_DATA/ollama-models).

WebUI data path: Open WebUI reads/writes app data from /app/backend/data inside the container, which maps to /mnt/nas/openwebui-data on VM 205, which is an NFS mount to 10.10.20.4:/openwebui-data on the QNAP NAS (internal path: /share/CACHEDEV1_DATA/openwebui-data).

Key Configuration Files

VM 205 – /etc/fstab (corrected):

10.10.20.4:/ollama-models  /mnt/nas/ollama-models  nfs defaults,_netdev,nofail,x-systemd.automount 0 0
10.10.20.4:/openwebui-data /mnt/nas/openwebui-data nfs defaults,_netdev,nofail,x-systemd.automount 0 0

VM 205 – docker-compose.yml:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports: ["11434:11434"]
    volumes: ["/mnt/nas/ollama-models:/root/.ollama"]
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports: ["3000:8080"]
    environment: ["OLLAMA_BASE_URI=http://ollama:11434"]
    volumes: ["/mnt/nas/openwebui-data:/app/backend/data"]
    depends_on: [ollama]

Lessons Learned

1. Always verify the NAS IP: The fstab had a stale IP (10.10.20.6) that no longer existed. The actual NAS was at 10.10.20.4.
2. QNAP != Synology paths: Synology uses /volume1/share-name, QNAP uses /share/CACHEDEV1_DATA/share-name internally and exports as /share-name.
3. Check /etc/exports directly: The QNAP web UI showed NFS enabled, but the underlying exports file had an invalid option (read-wr instead of rw), causing silent export failures.
4. showmount -e is your friend: Quick way to verify NFS exports are actually published.
5. Keep local backups: The docker-compose.yml.bak file preserved the original NAS-based config for easy restoration.

Status: Complete

Both Ollama models (9.8 GB, 4 models) and OpenWebUI data (890 MB) are now running from the QNAP NAS via NFS. The stack is fully operational with all 4 models accessible and OpenWebUI responding healthy on port 3000. Migration completed April 30, 2026.

This guide covers the essential steps for troubleshooting Proxmox boot failures and network recovery issues. Whether you’re dealing with a Proxmox VE node that won’t boot, network interfaces that fail to initialize, or connectivity problems after an update, this visual reference provides a structured approach to diagnosing and resolving common Proxmox infrastructure issue

Today I completed a BIOS update on my MSI MAG X570S Tomahawk Max WiFi motherboard, upgrading from the original BIOS Version 1.00 (dated 07/06/2021) to the latest Version 1.D1 (7D54v1D1, dated 09/19/2025). This update was performed using MSI’s M-FLASH utility as part of my Proxmox homelab infrastructure maintenance.

The visual guide above outlines the complete BIOS update process using MSI’s M-FLASH utility. Here’s a summary of the key steps performed:

• Downloaded BIOS version 7D54v1D1 from MSI official support page
• Extracted BIOS file (E7D54AMS.1D1) to a FAT32-formatted USB drive
• Stopped all Proxmox VMs and containers before rebooting
• Rebooted into BIOS and used M-FLASH to flash the new BIOS
• Verified critical BIOS settings: IOMMU enabled, SVM enabled, Above 4G Memory enabled, Re-Size BAR disabled
• Confirmed BIOS updated to Version 1.D1 (Release Date: 09/19/2025) via dmidecode

For detailed step-by-step documentation of this BIOS update process, visit the NetworkThinkTank-Labs GitHub repository. This motherboard serves as the foundation for my Proxmox homelab running GPU passthrough with an NVIDIA RTX 3060 Ti for AI workloads.

Some days in the homelab are quiet — a config tweak here, a firmware update there. And then there are days like today. April 29, 2026, turned into a full-blown infrastructure marathon: eight distinct projects spanning networking, virtualization, AI deployment, storage management, and documentation. Here is a complete rundown of everything that got done.

1. GitHub Documentation — 565 Lines of Technical Writing

Documentation is the backbone of any serious homelab. Today I pushed 565 lines of new documentation across multiple GitHub repositories. This included updated READMEs, configuration guides, topology diagrams, and step-by-step walkthroughs. Every project in my lab now has proper technical documentation that anyone can follow to replicate the setup. If it is not documented, it did not happen — and today, it all got documented.

2. EVE-NG CCNA Lab Updates — 29 Nodes

My EVE-NG CCNA lab got a major overhaul. The lab now contains 29 active nodes, covering routing, switching, and network services. This includes Cisco IOS routers and switches configured for OSPF, EIGRP, BGP, VLANs, STP, ACLs, NAT, and DHCP. The lab features API troubleshooting support, Proxmox migration readiness via Terraform and Ansible, and qcow2 image management. Whether you are studying for the CCNA or just want a robust network simulation environment, this lab has you covered.

3. Blog Post Publishing — 2,943 Words

Earlier this month, I published a comprehensive 2,943-word blog post on the Network ThinkTank blog covering how to self-host AI on a Proxmox homelab with Ollama and Open WebUI. Today’s writing adds to that momentum. Consistent publishing is key to building a knowledge base that helps both myself and the broader homelab community.

4. Ollama Models Deployment — 4 Models

Local AI is the future of privacy-conscious computing. Today I deployed four Ollama models on my Proxmox homelab, running inference entirely on local hardware. The models are served through Open WebUI, giving me a polished ChatGPT-like interface without any data leaving my network. No API keys, no cloud dependency, no privacy concerns — just pure local LLM power. The models cover different use cases from general conversation to code generation and technical assistance.

5. OpenClaw AI Agent Deployment

OpenClaw, an AI agent framework, was deployed and configured in the homelab today. This adds autonomous AI agent capabilities to the infrastructure, enabling task automation and intelligent workflows. The deployment involved setting up the agent runtime, configuring API endpoints, and testing basic agent interactions. This is a step toward building a more intelligent, self-managing homelab environment.

6. Windows Server VM Build

A fresh Windows Server virtual machine was built from scratch today. This VM will serve as a core infrastructure component for Active Directory, DNS, DHCP, and Group Policy management. The build process included creating the VM in the hypervisor, installing the OS, applying initial configurations, and setting up remote management. Having a Windows Server in the lab opens up enterprise-grade identity and access management capabilities.

7. NAS Storage Cleanup — ~20GB Freed

Storage hygiene is critical in any homelab environment. Today’s cleanup operation freed approximately 20GB of space on the NAS. This involved removing outdated VM snapshots, clearing old ISO images, purging stale Docker volumes, and archiving completed project files. A clean NAS is a happy NAS — and with 20GB reclaimed, there is plenty of room for new projects.

8. UniFi Network Server Installation

The UniFi Network Server was installed and configured today, bringing enterprise-grade network management to the homelab. This provides centralized control over UniFi access points, switches, and security gateways. The installation included setting up the controller software, adopting network devices, configuring wireless networks, and establishing monitoring dashboards. With UniFi in place, the entire network infrastructure can be managed from a single pane of glass.

Wrapping Up

Eight projects. One day. From AI deployments to network labs, from storage cleanup to documentation — today was a masterclass in homelab productivity. Every one of these projects builds on the others, creating a more capable, better-documented, and more resilient infrastructure.

The key takeaway? Documentation makes everything better. By writing things down — both in GitHub repos and blog posts — I am building a knowledge base that pays dividends every time I need to troubleshoot, replicate, or expand my setup.

If you are running a homelab, I encourage you to document your work, share your configs, and keep building. The community is stronger when we share what we learn.

Until next time — keep labbing.

Follow the Network ThinkTank blog for more homelab guides, networking tutorials, and infrastructure deep-dives. Check out the companion GitHub repositories at github.com/jczaldivar71 for configs, scripts, and technical documentation.

After weeks of building, troubleshooting, and optimizing my CCNA lab environment, I am excited to share the entire project — now fully documented and open-sourced on GitHub. This post walks through the journey from an initial EVE-NG deployment to a fully automated Proxmox-based lab using Terraform, Ansible, and custom shell scripts.

You can find the complete repository here: github.com/jczaldivar71/eve-ng-ccna-lab

Project Overview

The EVE-NG CCNA Lab project started as a straightforward network simulation environment for CCNA study. It quickly evolved into a full infrastructure-as-code project covering:

• EVE-NG lab deployment with API-driven automation
• Migration from EVE-NG to Proxmox for better performance and scalability
• Custom shell scripts for image management, licensing, and node orchestration
• A Python script (generate_readme.py) to auto-generate comprehensive documentation
• qcow2 disk image optimization achieving a 39% storage reduction
• Terraform and Ansible playbooks for reproducible infrastructure deployment

GitHub Documentation and the generate_readme.py Script

One of the key pieces of this project is the generate_readme.py Python script. Rather than manually maintaining a README that would inevitably fall out of sync with the actual project structure, I wrote a script that scans the repository and automatically generates a comprehensive README.md file.

The script inspects every directory — configs/, scripts/, terraform-ansible/, topology/, and images/ — and produces a fully formatted document with a table of contents, script references, setup instructions, and troubleshooting tips. Running it is as simple as:

cd scripts/
python generate_readme.py

The generated README covers 13 sections including Overview, Project Structure, Prerequisites, Quick Start, Lab Topology, Scripts Reference, qcow2 Image Management, EVE-NG API Usage, Proxmox Deployment, Configuration Files, Troubleshooting, Known Limitations, and License information. At 340 lines, it serves as a complete guide for anyone wanting to replicate or build upon this lab.

EVE-NG to Proxmox Migration

EVE-NG is a fantastic network emulation platform, but I ran into limitations around resource management and integration with modern IaC tools. The decision to migrate to Proxmox was driven by several factors:

• Better resource control: Proxmox provides fine-grained CPU, memory, and storage allocation through its API
• Terraform integration: The Proxmox Terraform provider enables declarative infrastructure definitions
• Thin provisioning: Proxmox handles thin-provisioned qcow2 images natively, which was critical for storage optimization
• Ansible compatibility: Post-deployment configuration is seamless with Ansible playbooks targeting Proxmox VMs

The migration involved exporting router and switch images from EVE-NG, converting and optimizing the qcow2 disk images, and then redeploying them on Proxmox using Terraform. The entire workflow is captured in the terraform-ansible/ directory of the repository.

Automation Scripts

The scripts/ directory contains six purpose-built shell scripts that automate every aspect of lab management:

• eve-ng-api-auth.sh: Handles cookie-based API authentication with EVE-NG, exporting session tokens for use in subsequent API calls. Includes examples for listing labs, getting node details, and starting all nodes.
• start-lab-nodes.sh: Automates the process of starting all lab nodes through the EVE-NG REST API with proper sequencing and health checks.
• scp-upload-images.sh: Securely transfers qcow2 images to the EVE-NG or Proxmox host via SCP with progress tracking and integrity verification.
• qcow2-optimize.sh: The image optimization workhorse — converts, compresses, and thin-provisions qcow2 disk images (more on this below).
• fix-permissions.sh: Ensures correct file ownership and permissions on EVE-NG image directories, a common source of lab startup failures.
• iol-license-fix.sh: Generates and applies the proper IOL (IOS on Linux) license file, which is required for Cisco IOL images to boot correctly.

Each script is documented with usage instructions and can be run independently or chained together for a complete deployment workflow.

qcow2 Image Optimization

One of the most impactful parts of this project was optimizing the qcow2 disk images. Network appliance images (Cisco IOSv, IOSvL2, CSR1000v, etc.) often ship with significant wasted space — preallocated but unused disk blocks that consume real storage.

The qcow2-optimize.sh script automates a multi-step optimization pipeline:

1. Sparsification: Uses virt-sparsify to zero out unused blocks within the guest filesystem
2. Compression: Applies qcow2 internal compression via qemu-img convert -c
3. Thin provisioning: Ensures metadata is set for thin-provisioned allocation on the hypervisor
4. Integrity check: Runs qemu-img check to verify image health post-optimization

The results were significant: total image storage dropped from 30GB to 18.3GB — a 39% reduction. This is especially meaningful in a home lab where storage is often limited. The optimized images boot identically to the originals but consume far less disk space on the Proxmox host.

Terraform and Ansible Deployment

The final piece of the puzzle is fully automated deployment using Terraform and Ansible. The terraform-ansible/ directory contains everything needed to stand up the lab from scratch:

Terraform handles the infrastructure provisioning:

• VM creation on Proxmox with defined CPU, memory, and disk parameters
• Network interface configuration with VLAN tagging
• Cloud-init integration for initial bootstrapping
• State management for tracking deployed resources

Ansible manages the post-deployment configuration:

• init-proxmox.yml: Initializes the Proxmox host with required packages, storage configuration, and network bridges
• deploy-vm.yml: Deploys individual VMs with their specific configurations
• remove-gateway.yml: Cleans up default gateway routes that can interfere with lab routing exercises

Configuration variables are stored in group_vars/all.yml (with a .sample template provided), and the hosts inventory file defines the Proxmox target. The ansible.cfg sets sensible defaults for host key checking and privilege escalation.

With this setup, spinning up a complete CCNA lab goes from a manual multi-hour process to a single command:

cd terraform-ansible/
terraform init && terraform apply
ansible-playbook -i hosts deploy-vm.yml

What’s Next

This project is a living repository — I plan to continue adding to it as I progress through my CCNA studies and expand the lab. Future additions may include:

• Additional topology configurations for specific CCNA exam topics
• Integration with network monitoring tools
• CI/CD pipeline for automated lab testing
• Support for additional platforms (VIRL, GNS3)

If you are studying for the CCNA or building your own home lab, feel free to fork the repository and adapt it to your needs. Contributions and feedback are always welcome.

GitHub Repository: https://github.com/jczaldivar71/eve-ng-ccna-lab

Transform your spare room into a career-accelerating network laboratory

If you’re serious about leveling up your networking skills, there’s no substitute for hands-on experience. Certifications are great. Books are essential. But nothing cements your understanding of BGP peering, VXLAN fabrics, or automation workflows like building it yourself and watching packets traverse your own infrastructure.

After 20+ years in networking — from pulling cable to managing backbone infrastructure at Lumen — I can tell you that the engineers who stand out are the ones who lab. They break things on purpose, fix them under pressure, and walk into production environments with confidence.

In this guide, I’ll walk you through everything you need to build a professional-grade home lab, from hardware selection to virtualization platforms to topology design. And because I believe in open-source learning, I’ve created a companion GitHub repository with sample configs, topology files, and scripts you can use to get started immediately.

GitHub Repo: NetworkThinkTank-Labs/home-lab-guide

Why Build a Home Lab?

Let’s get the obvious out of the way: you can’t become a great network engineer by reading alone. Here’s why a home lab is one of the best investments you can make in your career:

• Hands-on practice for certifications — CCNA, CCNP, JNCIA, and beyond all require you to understand how protocols actually behave, not just how they’re described in RFCs.
• Safe environment to break things — Production networks don’t forgive mistakes. Your lab does. Misconfigure OSPF areas? Blow up a spanning-tree topology? No pager going off at 2 AM.
• Real-world skill building — Employers want engineers who can troubleshoot, not just configure. A lab gives you the reps.
• Automation testing ground — Python scripts, Ansible playbooks, Netmiko sessions — test them here before you touch production.
• Portfolio building — Document your labs on GitHub and your blog. Show hiring managers what you can do, not just what you’ve memorized.

Hardware Recommendations

You don’t need to spend thousands of dollars to build an effective lab. Here’s a tiered approach based on budget and goals.

Tier 1: Budget Build ($200-$500)

Perfect for getting started with virtualization and basic routing/switching labs.

Tier 2: Intermediate Build ($500-$1,500)

For engineers running multiple VMs, nested virtualization, and more complex topologies.

Virtualization Platforms

This is where the magic happens. Modern network labs are predominantly virtual, and the platform you choose shapes your entire lab experience.

Proxmox VE (My Top Pick for Home Labs)

GNS3

Why: The OG network emulator. Runs real Cisco IOS/IOU images and integrates with QEMU/KVM for full OS emulation. Best for Cisco-centric labs and certification prep (CCNA/CCNP). Pair with our BGP Fundamentals Lab and VPN IPSec/GRE Lab.

EVE-NG

Why: Web-based, multi-vendor support, great for complex topologies with dozens of nodes. Best for multi-vendor labs (Cisco, Juniper, Arista, Palo Alto, Fortinet). Pair with our EVPN-VXLAN Lab for data center fabric simulation.

Containerlab

Why: Lightweight, code-defined network topologies using containers. Perfect for modern network automation workflows. Uses Docker containers running network OS images (cEOS, FRR, Nokia SR Linux). Define topologies in YAML and version control them in Git. Pair with our Network Automation with Ansible Lab.

Designing Your Network Topology

A well-designed lab topology mirrors real-world architectures. Here are three topologies I recommend, progressing from simple to advanced.

Topology 1: The Starter Lab

Internet > Firewall (pfSense/OPNsense) > Core Switch (L3, VLAN trunking) > VLANs (Management, Lab, Servers)

What you’ll learn: VLANs, inter-VLAN routing, firewall rules, NAT, DHCP

Topology 2: The Enterprise Lab

Dual ISP routers with eBGP > Edge Router (BGP AS 65000) > Core switches (OSPF, LACP) > Access switches

What you’ll learn: BGP peering, OSPF areas, HSRP/VRRP, link aggregation, redundancy

Topology 3: The Data Center Fabric

Spine-01/Spine-02 > Leaf-01 through Leaf-04 > Server clusters

What you’ll learn: EVPN-VXLAN, BGP underlay/overlay, spine-leaf architecture, network automation at scale. Check out our EVPN-VXLAN Lab for a full walkthrough.

Essential Software Tools

Network Management and Monitoring

• LibreNMS or Zabbix – SNMP-based monitoring, alerting, graphing
• Grafana + Prometheus – Modern dashboards and metrics visualization
• Wireshark – Packet capture and protocol analysis

Automation and DevOps

• Ansible – Agentless configuration management (Ansible automation lab)
• Python + Netmiko/NAPALM – Script-driven device management (network-backup-automation repo)
• Git – Version control everything: configs, scripts, documentation
• Docker – Containerize your tools and services

• LibreNMS or Zabbix – SNMP-based monitoring, alerting, graphing
• Grafana + Prometheus – Modern dashboards and metrics visualization
• Wireshark – Packet capture and protocol analysis

Automation and DevOps

• Ansible – Agentless configuration management (automation lab)
• Python + Netmiko/NAPALM – Script-driven device management (backup automation)
• Git – Version control everything: configs, scripts, documentation
• Docker – Containerize your tools and services

The Lab Exercise Workflow

Here’s how I approach lab exercises, and how you can use the NetworkThinkTank-Labs repositories to follow along:

1. Define Your Objective – Pick a protocol or concept. Example: “I want to understand eBGP peering between two autonomous systems.”
2. Build the Topology – Use GNS3, EVE-NG, or Containerlab to spin up the required nodes. Clone the relevant repo.
3. Configure – Follow the lab guide’s step-by-step configs. Type them manually — don’t just paste. Muscle memory matters.
4. Verify – Use show commands, ping tests, traceroutes, and Wireshark captures to verify your work.
5. Break It – Intentionally introduce failures. Shut down a link. Add a route filter. Change an AS number. Watch what happens and troubleshoot.
6. Document – Write up what you learned. Push your configs to your own GitHub fork. Blog about it.

The Lab Exercise Workflow

1. Define Your Objective – Pick a protocol or concept to learn.
2. Build the Topology – Use GNS3, EVE-NG, or Containerlab.
3. Configure – Type configs manually for muscle memory.
4. Verify – Use show commands, pings, and Wireshark.
5. Break It – Introduce failures and troubleshoot.
6. Document – Push configs to GitHub and blog about it.