Homelab / Technical documentation
The homelab, from migration to operations.
How I moved from a CasaOS laptop to two Proxmox hosts, built the services around them, and investigated failures along the way.
What I built
I use this lab for media, documents, home automation and the software I build to manage it. The work spans migration, persistent storage, hardware encoding, scanning, networking and service diagnostics.
The main application stack runs in a Debian VM on the HP. The ASUS is now a second Proxmox host, with Home Assistant OS in its own VM and Pi-hole and Uptime Kuma in a separate Debian VM. This completed conversion is User-confirmed · 8 November 2026.
Evidence: S19.
Choose a starting point
- Understand the deployment
Host, guest and container boundaries, reconciled against the latest confirmation.
- Follow the migration
Preserving application state and container paths while moving runtimes.
- Read the incident records
Disk recovery, Plex containment, DNS and a playback workaround, with bounded conclusions.
- Inspect the software decisions
Source-backed architecture and the distinction between the old failed image and the newer deployment.
What each status means
Scroll within the table to see all columns.
| Record | Status and scope |
|---|---|
| Two-node guest layout | User-confirmed on 8 November; no cluster or failover claim. |
| Migration, storage recovery and scanning | Historical work supported by the supplied reconstruction. |
| VA-API segment test | Observed output in the reconstructed transcript; QSV remained a separate failure. |
| Command Center | Newer source inspected; 7 November deployment report records healthy operation and persistence checks. |
| Fresh server inventory | Not obtained in this review. The existing SSH control session was unavailable. |
Exact missing operational evidence is kept in a private verification list. Public limitations appear where they change how a result or example should be interpreted.