Reclaim and right-size¶

New in the next release

This is on the dev and qa builds now, and in the next release.

Below the Capacity table, Reclaim and right-size lists capacity you could take back, and how much each suggestion gives back. Its top line totals it all: "following every suggestion would give back 24 vCPU, 96 GiB memory, 1.2 TiB disk."

Ferrule changes nothing. These are suggestions to take to whoever owns the VM.

The suggestions¶

VMs are judged over the last 30 days, and only once Ferrule has at least 21 of them for that VM. The panel says how many VMs have that much history. A VM that's on some days and off others isn't judged: it's in use, just not always.

Suggestion	When	Gives back	Suggests
Powered off	Off for every day of the window	Its vCPUs, memory and provisioned disk	Retire or remove it
Idle	On every day, but its CPU never above 5% of its vCPUs, and, where the guest reports it, its memory never above 20%	The same	Probably forgotten: retire or remove
Too many vCPUs	Two or more vCPUs, and its busiest day's 95th percentile, plus a quarter, is under half of them	The difference	The count to set, at least one
Too much memory	At least 2 GiB, the guest reports its memory, and its busiest day plus a quarter is under half	The difference, in whole GiB	The size to set
Old snapshot	Older than a week	Its age (the inventory doesn't record a snapshot's size)	Remove it
Orphaned disk	A disk file no VM uses	Its size on disk	Check, then delete

"A quarter on top" is the margin: a VM that peaked at 1.5 cores gets a suggestion of 2, not 1.5.

Memory is judged only where the guest's own use is reported: by VMware Tools on vCenter, and on Proxmox VE by the memory figure Proxmox reports for the guest. Without it, a VM is never called oversized on memory, and "idle" goes by CPU alone.

CPU for vCenter VMs is counted in cores, from each VM's clock against its host's.

Orphaned disks¶

Disk files no VM uses: a VM removed from the inventory but not deleted from disk, a disk detached and forgotten, the leftovers of a failed migration. They're found by the daily inventory, so they're as fresh as the newest one.

vCenter¶

Ferrule browses every accessible datastore for .vmdk files and compares them with every registered VM's files, snapshot deltas included.

It says	Meaning
no VM uses it	It's in a folder no registered VM uses: usually a VM removed from the inventory without deleting its files
in a VM's folder, but not one of its disks	It sits with a VM but isn't attached: a disk removed from the VM but kept on disk

Left out on purpose, because something else looks after them:

content library items (contentlib-… folders);
first-class disks (fcd/), used by Kubernetes;
vSphere Replication files (hbrdisk…);
change-tracking files (-ctk.vmdk);
hidden folders (.…).

Browsing needs the read-only Datastore → Browse datastore privilege, which the Read-only role doesn't have. Without it, the panel names each datastore it couldn't search and says what to grant. See vCenter.

Proxmox VE¶

Ferrule lists each disk storage's volumes and compares them with every guest's config.

It says	Meaning
no VM uses it	A volume of a guest that no longer exists
in a VM's folder, but not one of its disks	Its guest exists, but no longer names it
detached from its VM but kept in its config	Listed as `unusedN` in the guest's config

Left alone on purpose:

a guest Ferrule couldn't read (its node is down): nothing is said about its volumes;
a snapshot's saved memory (…-state-…);
a template's base disk, and a linked clone's disks, which belong to it.

It needs no more than the PVEAuditor role.

Before you delete anything¶

Check first

A datastore shared with another vCenter, or a storage shared with another cluster, that Ferrule doesn't watch holds that one's disks too, and they look orphaned from here. So do disks kept on purpose, outside any VM. Ferrule only reports; deleting is yours to decide.

The last written date helps: a file untouched for a year is a safer bet than one written last night.

Where else they show¶

The inventory downloads' Orphaned disks sheet, which is keyed, so a new orphan appears on the Changes sheet.
The reporting database's orphaned_disks table.
The monthly summary's "What could be reclaimed".

Per-VM history¶

To judge VMs, Ferrule keeps a daily summary per VM (vCPUs, memory, CPU and memory use) for about three months, in capacity/vm-*.jsonl on its volume. The same history drives moving VMs.