Windows Server is the backbone of the lab. It's the Hyper-V host every other VM runs on — Linux included — and it's also the box handling DNS and DHCP for the whole network. Everything else in the lab depends on this working correctly.
Hyper-V hosting
Every VM in the lab, Linux and Windows alike, runs as a guest on this Hyper-V host. That means setting up virtual switches, allocating resources per VM, and keeping the host itself patched and healthy since everything else is riding on it. Running Linux workloads on a Windows hypervisor rather than a Linux-native one is deliberate — it keeps me fluent in both, since it's what I run into at work too.
DNS & DHCP
The server handles internal name resolution for the browntown.local domain, so every device and service in the lab — the Omada controller, internal dashboards, VMs — gets a clean hostname instead of a raw IP. DHCP scoping runs alongside it, handing out addresses and keeping reservations consistent for anything that needs a stable IP, like the switch and the wireless controller.
What it's taught me
- Running DNS and DHCP for a network real devices actually depend on surfaces problems that a lab-only setup never would — a bad scope or a stale record breaks something visibly, right away.
- Hosting Linux guests on Hyper-V instead of defaulting to something like Proxmox keeps my Windows virtualization skills sharp, since that's the environment I support professionally.
- Keeping the host server healthy is a different kind of responsibility than managing an end-user machine — everything downstream depends on it staying up.
What's next
- Document the DHCP scopes and reservations as a proper reference
- Set up scheduled backups of the Hyper-V host configuration