Home server

Why build a home server

Although cloud hosting is convenient it is expensive when running more services. In my case; eight virtual machines on AWS would be cost prohibitive. Running all the services on my own gives me complete control over every aspect of the project. This control also means that I need to understand all the parts that go into the final project. I need to know how the hypervisor works, I need to setup the networking, I need to setup the dependencies for each virtual machine. I will touch every part every part of the deployment. Having hands-on with every part of the project helps me in a security role understand where threats can come from and also allows me to limit those risks through least access.

Hardware

The server is a Dell Precision 3650 tower workstation. I chose it for the enterprise-grade components and room for upgrades down the line.

Component	Specification	Why it matters
CPU	Xeon W-1370P, 8 cores / 16 threads, 5.2 GHz turbo	Workstation-grade. Strong single-core and multi-core performance for concurrent virtualized workloads.
RAM	32 GB DDR4-2400, non-ECC unbuffered (4x8GB)	16GB always-on services + headroom for on-demand VMs. Upgraded from factory 16GB.
Storage	500 GB NVMe SSD	NVMe for VM disks and Elasticsearch I/O.
Network	Intel Gigabit Ethernet	Intel NICs have the best Proxmox driver support. Wired, not WiFi for greater stability and reliability.

Hypervisor

Proxmox VE 9.1 runs directly on bare metal. Compared to Hyper-V on Windows 11 which I have used previously, Proxmox reclaims around 2-3 GB of RAM that Windows consumed as the host OS, provides cleaner CPU scheduling without background Windows processes fighting for resources, and offers native Linux bridge support for a more flexible networking stack.

The decision to migrate from Hyper-V to Proxmox was made early in the project. Losing the Windows desktop had no impact since every service on the server is accessed remotely either through SSH, Kibana via browser, Jellyfin via app, and Proxmox through its own web interface. After using both, Proxmox provides better VM management.

Network architecture

Two Linux bridges segment traffic by trust level. All production services share the LAN bridge while the cyber sandbox runs on a completely isolated bridge with no route to the internet.

vmbr0 — LAN

Connected to the physical NIC. All production VMs and containers attach here and are accessible from any device on the home network. DHCP reservations in the router ensure every VM gets a consistent IP so things do not break when the server reboots.

vmbr1 — Isolated sandbox

No physical NIC, no gateway, no internet access. Kali Linux and FlareVM connect here exclusively. When running malware analysis or attack simulations, traffic stays contained within this bridge. No detonated malware sample can phone home, which is the whole point.

Virtual machines and containers

Always-on services

SOC lab — on-demand

Cyber sandbox — vmbr1

Resource allocation

With 32 GB total RAM and 16 threads, the server comfortably runs all always-on services while leaving headroom for on-demand lab work. The principle is simple: services that run 24/7 get dedicated, non-ballooned resources while on-demand VMs are sized for their workload and are only online when being used.

Always-on:   16 GB RAM · 12 vCPU
On-demand:  +14 GB RAM · +8 vCPU  (endpoints + sandbox, not simultaneous)
Proxmox:     ~2 GB RAM
Total:       32 GB · 16 threads

vCPUs are overcommitted if all VMs are online at the same time, this isn't a problem because that will never occur all running at the same time, and if it did, Proxmox time-shares vCPUs efficiently across workloads.

Build decisions

Why Proxmox over Hyper-V

The project initially ran on Windows 11 Pro with Hyper-V. The migration to Proxmox was driven by three factors: reclaiming the 4 GB of RAM consumed by Windows, getting rid of background Windows processes that competed for CPU time with the virtualized workloads, and gaining access to LXC containers for lightweight services like Jellyfin and Nextcloud. In hindsight, this should have been the starting point.

Why i440fx over q35

The Ubuntu 24.04 installer every time on q35 with OVMF/UEFI in Proxmox VE 9.1. Switching to i440fx with SeaBIOS resolved it. For my home server the performance difference is negligible, q35 would boost PCIe passthrough or Secure Boot performance, neither of which are needed here.

Intel NIC hardware hang

The Dell Precision 3650 uses an Intel I219 Gigabit NIC driven by the e1000e kernel module. Under sustained virtualized network load, the NIC intermittently freezes, the kernel logs repeated "Detected Hardware Unit Hang" errors, all VM connectivity drops, and the host eventually becomes unresponsive. This is a well-documented issue with the I219 family on Linux but it took some digging through kernel logs to identify since it does not appear in the Intel NIC driver support documentation for Proxmox.

The fix is disabling TCP/UDP offloading features that trigger the hang. Adding post-up directives to /etc/network/interfaces makes the workaround persistent across reboots:

iface nic0 inet manual
        post-up /usr/sbin/ethtool -K nic0 tso off gso off gro off
        post-up /usr/sbin/ethtool --set-eee nic0 eee off

Disabling Energy Efficient Ethernet (EEE) addresses a second failure mode where the NIC's power-saving state transitions cause brief link drops. With both fixes applied, the host has been stable since.

Why LXC for Jellyfin and Nextcloud

Both services are simple Linux applications that do not need their own kernel. LXC containers share the Proxmox host kernel, start in seconds, and use a fraction of the RAM compared to a full KVM virtual machine. A full Ubuntu VM for Nextcloud would consume 2 GB doing nothing while an LXC container runs the same service in 256-512 MB. When resources are limited, this difference matters.

What I would change

Start with Proxmox from day one. The time spent configuring Hyper-V was wasted when the migration happened. If the plan includes bare metal virtualization, commit to it upfront.

Connecting the server to a UPS would protect against power outages and prevent data corruption on VMs during unexpected shutdowns. A UPS also enables the server to shutdown gracefully during outages.

Go with a 1TB NVMe from the start. The 500GB drive fills faster than expected once you are allocating 60-100GB per VM, and resizing virtual disks after the fact is more disruptive than sizing the drive correctly upfront. Adding a secondary SSD dedicated to media storage for Jellyfin, nextcloud, and VM snapshots would also keep the primary NVMe focused on active VM workloads.

Switching to a faster internet service provider would expand the usability of the server, games could be played with friends not on the local LAN, movies could be watched away from home, and documents could be backed up from remote locations. The current setup is great for local use and learning how to use the services, but for them to actually be useful, higher bandwidth is required. This would also create more diverse logs which would make the SIEM more useful.