Building My Homelab: One Refurbished PC and Hyper-V

Every “how to get into IT” list says the same things: portfolio projects, certifications, and a homelab. The first two are easy to picture. The homelab is harder. A room full of servers running 24/7? Switches, routers, firewalls, a perfect security setup? Or just a place to try things and build skills?

Whatever it looks like, a homelab is worth having because the problems are real. You click through things that courses only describe. You break something and spend hours on a problem that a cert covers in one sentence. That’s the “getting your hands dirty” part: things that take hours the first time and minutes the second. The goal is intuition, a sense of where the problem probably is instead of wandering through a maze.

Why I needed one

School (Applied Informatics) and cert material (Cisco CCST, CCNA) give you knowledge but not that experience. Without an IT job, I had nowhere to experiment safely, and you shouldn’t experiment on production anyway. A homelab solved both: somewhere I can break things on purpose (GPO, DNS, replication) and document the fix, and a source of real tickets and runbooks for my IT portfolio instead of made-up scenarios.

Picking the hardware

My first attempt was a laptop with 8 GB of RAM. Even Fedora wasn’t always quick on it. Leaving Windows for Linux doesn’t turn 8 GB into 16. Searching for something “future-proof” with enough CPU and RAM quickly leads to four-digit prices, or close to it.

So the real question was what I actually wanted. A server room with a full ecosystem of services? No. A machine that could run virtual machines now and maybe become a dedicated lab server later. That set the requirements: one box that runs Hyper-V with at least two VMs at once (a server and a client), quiet and low-power enough to stay on at home without anyone hearing it or seeing it on the electricity bill.

I went with refurbished instead of new, for three reasons:

• Money. At the start I didn’t know if I’d stick with this. It made no sense to buy new hardware before the lab proved it was worth it.
• Environment. Extending the life of an existing machine has a smaller footprint than making a new one. Most of a computer’s carbon cost is baked in during manufacturing, not use.
• Upgrade later. The refurbished box is a deliberate first step. Better hardware comes when the lab outgrows it.

The same reasoning drove the specs:

• 32 GB RAM, not 16. The one place worth paying extra. RAM is the first thing that runs out with several VMs running at once.
• 512 GB SSD, not 1 TB. 1 TB would be nice, but a few VMs fit fine. It’s a lab, not an archive.
• Low power draw. It runs all the time, so watts show up on the bill.

What I bought:

The “Tiny” form factor and the “T” CPU (35 W TDP instead of 65 W for the regular i7-8700) weren’t accidents. Both serve the goal of a quiet, efficient machine that stays on.

Virtual first, physical later

The second decision was to start with virtualization on one host instead of buying two physical machines. Same reasons as the hardware: lower cost, and much easier experimenting. A bad step rolls back to a checkpoint in seconds instead of a reinstall. Working with Hyper-V is also a skill I want in its own right, not just a means to an end.

What runs today

An internal virtual switch, LabNetwork, on 192.168.10.0/24. On it:

• DC01: Windows Server 2025 Standard (evaluation). Domain controller for lab.local, DNS, and DHCP (scope .100–.200, static .10 for itself).
• CL01: Windows 11 Enterprise (evaluation), joined to the domain, with a checkpoint taken right after the join.

A separate Microsoft 365 test tenant handles licensing, users, and basic security policies. It’s not connected to the local AD yet.

Two choices behind that:

• Server 2025, not 2022. I wanted to learn on the current LTSC release so the skills match today’s job market, not on a version getting close to the end of its mainstream cycle.
• Enterprise, not Pro. I wanted the full feature set real enterprise environments use, like AppLocker and other central management tools. One client is enough for now.

One lesson already learned

Checkpoints make experimenting cheap, but restoring an old checkpoint of a domain-joined machine can break things in ways that aren’t obvious. The computer’s account password in AD moves on, the restored machine still has the old one, and the trust relationship fails. Rolling back a domain controller is worse, because it can break replication. The rule I follow now: take a checkpoint before every “break it” exercise, and restore clients rather than DCs. I wrote it up as a ticket: T-004, secure channel failure (in Slovak).

What’s next

• A second domain controller on Server 2022. Not only for redundancy. A different version on purpose, to practise two versions side by side and migrating between them. Real upgrade projects rarely run on a single version.
• A Windows 11 Pro client next to Enterprise, to see the edition differences in practice and not just in a table.
• An Ubuntu machine, because real helpdesks support mixed Windows and Linux environments.
• Better hardware, exactly as planned, once this box can’t run enough VMs at once.

The full build steps, from enabling Hyper-V to joining a client to the domain, are in my lab notes (Slovak): part 1 and part 2.