From 324933790553cc58dd3230374cb6e0b6f7003050 Mon Sep 17 00:00:00 2001 From: Garrett Allen <98648590+Gerrrt@users.noreply.github.com> Date: Mon, 9 Nov 2026 00:29:29 +0000 Subject: [PATCH] feat(tofu): grow garuda's disk from 80 to 120 GB MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit GuestDiskWillFillIn24h paged for garuda on 2026-11-08. Nothing was filling: one 5.4 GiB step at 21:24 UTC, the OpenVAS (gvmd) database writing, read by the six-hour window as a trend. gvmd alone is 24 GB, and with 16 GB left the next feed sync or large scan pages again. The runbook's §14 says how to apply it: a targeted plan that must change the disk size alone, then growpart and resize2fs on the guest. Co-Authored-By: Claude Opus 5.5 --- docs/changelog.md | 13 +++++++++ .../runbooks/build-the-analyst-workstation.md | 28 +++++++++++++++++-- tofu/guests.tf | 2 +- 3 files changed, 40 insertions(+), 3 deletions(-) diff --git a/docs/changelog.md b/docs/changelog.md index d71bba6b..b24dae78 100644 --- a/docs/changelog.md +++ b/docs/changelog.md @@ -17,6 +17,19 @@ roadmap as it read that day, and the *Done* entries keep the shape they had there. `check_docs.py` does not check this file, for the reason its module docstring gives: it is a record, not a claim about now. +## 2026-11-09 + +- **`GuestDiskWillFillIn24h` paged for `garuda`, and the disk goes from 80 to + 120 GB.** `/` went from 51.6 to 57.2 GiB between 21:24 and 21:44 UTC on + 2026-11-08 and was flat afterwards; six hours of window read the one step as + a climb of 1.2 GiB an hour. Nothing was filling. The step was the OpenVAS + database (ADR-0093): `/var/lib/postgresql` is 25 GB, all of it the `gvmd` + database (24 GB) and its 1 GB `pg_wal` floor, on one PostgreSQL 18 cluster. + Docker held under 1 GB. `apt clean` freed the package cache. With 16 GB free + after that, the next feed sync or large scan would page again, so + `tofu/guests.tf` raises `disk_gib`, and `build-the-analyst-workstation.md` + §14 says how to apply it. + ## 2026-11-08 - **[#574](https://github.com/Gerrrt/HomeLab/issues/574): the UPS shutdown diff --git a/docs/runbooks/build-the-analyst-workstation.md b/docs/runbooks/build-the-analyst-workstation.md index aa75e347..7eab9b8a 100644 --- a/docs/runbooks/build-the-analyst-workstation.md +++ b/docs/runbooks/build-the-analyst-workstation.md @@ -47,7 +47,7 @@ Enrolling `garuda` in Wazuh and Velociraptor is §12, phase 2. OpenVAS, phase | Tags | `analyst`, **not** `on-demand` | Always on. `HypervisorGuestStopped` should find it stopped ([ADR-0079](../adr/0079-tag-on-demand-guests-and-leave-them-out-of-the-stopped-guest-alert.md)) | | `onboot` | `1`, no startup order | Nothing waits for it, and it waits for nothing | | vCPU / RAM | 4 / 8 GiB | A desktop, Wireshark on a capture, and Defense's `siemup` lab during an exercise | -| Disk | 80 GB on `large_data` | Captures, cases and scan results. The template's own disk is 64 | +| Disk | 120 GB on `large_data` | Captures, cases and scan results, and the OpenVAS database (ADR-0093), which alone was 24 GB on 2026-11-09. Built at 80, grown in place; the template's own disk is 64 | | Domain | **Not joined** | The domain is the target and is reverted. A member would fall with it, notes and all (ADR-0091) | | SIEM and sensors | **Off** | Wazuh, Zeek and Suricata already run. Their binaries stay, for offline work on a pcap; their daemons do not | | Backup | **Yes**, `golem`'s nightly job | Its case notes are not in git | @@ -66,7 +66,7 @@ Enrolling `garuda` in Wazuh and Velociraptor is §12, phase 2. OpenVAS, phase its address. 2. **On `Saruman`:** check `large_data`, as [`build-the-bloodhound-guest.md`](build-the-bloodhound-guest.md) §1 does. - This guest adds 80 GiB to the thin allocation. + This guest adds 120 GiB to the thin allocation. ```bash pvesm status | grep -E 'large_data|local-lvm' @@ -688,3 +688,27 @@ the Wazuh agent and the Velociraptor client, as Debian packages staged on - `garuda`'s key in the `analyst` rule of `.sops.yaml`, back to the placeholder or the rule removed with the stack 4. Destroy template 910 only if nothing else clones it. + +## 14. Grow its disk + +`disk_gib` in `tofu/guests.tf` is the size. The provider grows a disk in place, +online, and refuses to shrink one. `/` is the last partition (§11, #1128), so +the guest takes the new space with no reboot. + +1. Check the room on `Saruman`, as §2 does. +2. On `phoenix`, after the pull request that raises `disk_gib` merges: + + ```bash + tofu -chdir=tofu plan -target='module.guest["garuda"]' + ``` + + The plan must read **0 to add, 1 to change, 0 to destroy**, and the change + must be the disk's `size` alone. Anything that replaces the guest stops + here. Then `apply` the same target. +3. On `garuda`: + + ```bash + sudo growpart /dev/sda 2 && sudo resize2fs /dev/sda2 && df -h / + ``` + + Read the device from `lsblk` first if the layout has changed since §11. diff --git a/tofu/guests.tf b/tofu/guests.tf index 4bbc18b9..7e1365f9 100644 --- a/tofu/guests.tf +++ b/tofu/guests.tf @@ -131,7 +131,7 @@ locals { # module's `operator`, for the reason the dotfiles VMs give below. analyst = { for name, g in { - garuda = { vm_id = 162, template = 910, cores = 4, memory_mib = 8192, disk_gib = 80, mac_address = "BC:24:11:ED:98:3F" } + garuda = { vm_id = 162, template = 910, cores = 4, memory_mib = 8192, disk_gib = 120, mac_address = "BC:24:11:ED:98:3F" } } : name => merge(g, { pool = "analyst"