No infrastructure changed in this one. It was documentation only, and that was the whole job: the hardware doc for the lab node had been frozen since early July, so it still described the original single-VM setup and nothing that came after it. No second VM. No memory investigation. No e1000e NIC driver bug and its persistent fix. No vzdump plus Cloudflare R2 backup pipeline. All of it already done and already verified, and none of it written down.
That is the part I want to remember. A doc a month behind does not read as stale, it reads as finished. Anyone opening the repo gets a confident description of a lab that no longer exists, and that anyone includes me, six months from now. It does not help that the note cannot even agree with itself about what the file is called.
Settle it against the machine, not against your memory
The memory question got closed the right way, and the method is the actual lesson. Instead of reasoning from the photo of the board and from what I remembered ordering, I asked the hardware directly with dmidecode: 2x8 GB DDR4-2666, both slots physically full. That changes the upgrade path more than I had realised. There is no free slot, so 32 GB is a replacement job — both sticks out, a fresh 2x16 GB kit in. About ten seconds of confirmation against an assumption I had been carrying for a month.
The same session also fixed an ordinary wrong description: the first VM was still written up as the generic Docker box from the original build, when it now has a specific job, had been resized down to 3 vCPU and 6 GB, moved to a static address, and given a second disk with no backups on it so it can keep its own internal backups there.
The decision was about what not to write down
Two questions were still genuinely open: where the trading bot ends up living, and how authority splits between the two machines. They were fresh in my head, and it would have been easy to fold them into the doc as though they were settled.
I left them out. A machine doc should only say what is true right now; anything still being decided belongs in a decision log, marked as unsettled. A proposal baked into a factual document is a quieter kind of staleness than falling behind on time, and harder to notice, because nothing about it looks wrong.
What I did not resolve
The storage layout is inferred, not verified. local-lvm is present, so ext4 plus LVM-thin is almost certainly what is running and the ZFS I intended never happened — but I never confirmed it directly. On a single disk there is no redundancy either way, so it is a revisit-if-a-second-disk-turns-up item, not an urgent one.
Part of the first VM's record came from a session summary rather than the raw transcript, so it deserves a check against the hypervisor's own configuration rather than against my notes.
Two sections of the knowledge base still describe the newer RHEL VM as being built. It is not; it just never got updated.
Still open on purpose: a shared network and topology doc for the repeater path, because that is lab-wide infrastructure rather than one machine's business. Proposed, not started.
If you are reading this before trusting that doc for anything: the two inferences above are the soft spots, and the RAM slots are full, so any memory growth is a replacement job.