Volume 2 Lab Environment

Volume 1 ended with a complete network design. Traffic types, VLAN assignments, IP ranges, bridge names, port matrices, an IPv6 plan. Every number I needed was written down.

And not one packet had moved.

That is the honest situation at the end of Volume 1, and I want to name it clearly rather than glide past it. A design that has never been built is a hypothesis. It is a good hypothesis, researched against the official documentation and reasoned through carefully, but it has never once been contradicted by a machine. That is not the same thing as knowledge.

Why this is not a Linux fundamentals volume

The original plan for Volume 2 was Linux administration. Users, groups, SSH, systemd, filesystems. I scratched it, and I want to say that plainly, because "I skipped the fundamentals" sounds like a red flag until you know where those fundamentals actually live.

Here is the decision in one sentence: this knowledge base already has a home for Linux fundamentals, and duplicating that material inside the HostKid project would make both places worse. Enormous docs that repeat the same systemd explainer twice help nobody. Volume 2 exists to get straight to the point — building the lab, wiring the network, standing up CloudStack — not to re-teach Linux from zero inside a project track.

If you need the fundamentals first, that is not a gap in this volume. That is what the Linux foundations section is for: a progressive path through the operating system itself, separate from any one project. Read that when you want the mental model. Come back here when you want the rack on your laptop.

The constraint, stated honestly

I am building a datacenter simulation on the laptop I also work on. Here is what I actually have, measured rather than assumed:

The whole resource ledger, and the discipline for living inside it, is worked out in lab architecture and resource budget.

What gets simulated, and what gets faked

The interesting engineering question in a lab like this is not "how do I make it run". It is which parts must be real and which parts may be pretend. Get that wrong in either direction and the lab is worthless: too much pretending and it teaches nothing, too much realism and it never boots.

My rule was this: anything that CloudStack touches, or that I would have to configure on real hardware, must be genuinely real. Anything that only exists because production has redundancy or physical separation may be collapsed.

Every collapse above is recorded in a deviation register in the architecture document, with the production equivalent written next to it. That register is the thing that stops a lab from quietly becoming a lie you believe.

The three levels of nesting

This is the mental model that makes everything else in the volume readable. There are three floors, and confusing them is the single biggest source of "why is this not working".

The software I chose, and the one-line reason

The full reasoning, including what I rejected, is in the architecture document. The short version so you know what you are installing:

How this volume is organised

Four documents, in build order. They are meant to be executed in sequence, not browsed.

The gate that ends this volume

I do not consider Volume 2 finished because the documents are written. I consider it finished when these are all true on my own machine:

Next

Start with lab architecture and resource budget. It is the only document in this volume with no commands in it, and it is the one that decides whether the other three work.

After this volume, Volume 3 revisits the platform decision with the benefit of having actually run the thing, and Volume 7 picks up the CloudStack API that this volume leaves authenticated and waiting.