Rich Gibbs

Cut a Docker VM from 8 GB after measuring RAM

homelab · docker · debian · qemu · rsync

Lab note for a Debian 13.6 Docker VM. Created 2026-07-17 with Docker CE and agents migrated off AWS by rsync pull. On 2026-08-21 it moved from DHCP to a static NIC reservation and dropped from 4 vCPU / 8 GB to 3 vCPU / 6 GB because measured RAM sat well under allocation. Storage is 32 GB on local-lvm (NVMe-backed) plus a 16 GB second disk left out of host backup for the app's own backups.

This VM hosts Docker and a self-hosted agent system migrated off AWS.

The useful line is the 2026-08-21 resize. I cut it from 4 vCPU and 8 GB to 3 vCPU and 6 GB (6144 MiB) after measuring actual RAM. Usage was well under allocation, so the unused headroom went to another VM on the same host. That was measurement, not a guess.

The note then records 3 vCPU (CPU type host), 6 GB RAM, and Debian 13.6 (Trixie). QEMU guest agent is installed and running.

How it got there: 2026-07-17, VM created, Docker CE installed, agents migrated from AWS via rsync pull. No transfer size, no rsync flags, no container list.

Addressing started as DHCP. On 2026-08-21 it moved to a static reservation tied to the NIC, for reliability. The note does not record an outage.

Storage is 32 GB on local-lvm, described as NVMe-backed, plus a second 16 GB disk on scsi1 with backup=0. That disk is for the guest application's own internal backups.

— Rich

Frequently asked questions

Why cut the guest from 4 vCPU and 8 GB to 3 vCPU and 6 GB?

RAM usage was measured and sat well under allocation. The cut freed headroom for another VM on the same host, instead of guessing at need.

What is the second 16 GB disk for?

It is a scsi1 disk flagged backup=0, used for the guest application's own internal backups, so host-level backup does not include that disk.

Why move from DHCP to a static reservation?

The note calls it a reliability move, tied to the NIC. It does not record an outage, a collision, or lost access.