# F5OS tenant config explainer

> Paste an f5-tenants:tenants block, from the CLI or from RESTCONF, and get it read back plainly: the configured / provisioned / deployed lifecycle and what each state means, the image and platform it belongs to, blades and VLANs, and the memory allocation checked against F5's published minimum of (3.5 × 1024 × vCPU) + 512. Local and offline.

- Tool: https://ronutz.com/en/tools/f5os-tenant-config-explainer
- Family: Operations & Fieldcraft

---

## What it does

Paste an `f5-tenants:tenants` block — the CLI form or the RESTCONF JSON — and the tool reads it back: the lifecycle state and what it means, the image and which platform it belongs to, the blades and VLANs, and each field explained. Local and offline; it parses the text and contacts no platform.

## The check that makes it more than a glossary

F5 publishes the minimum memory as **(3.5 × 1024 × vCPU) + 512**, so two vCPUs need 7680 MB and four need 14848 MB. The tool computes that minimum and **shows it beside the configured value**, warning when the allocation is below it.

It also warns when a vCPU count appears with no memory value, because **the two move together**: raising cores alone leaves the tenant below its new minimum.

## The lifecycle rule it states

**To change vCPU or memory on a deployed tenant you must move it back to `provisioned` first**, make the change, then return it to `deployed`. It is not a live operation, and the tool says so on every deployed tenant rather than waiting to be asked.

## Platform shape

It flags what belongs to which machine. **VELOS** is a chassis — `nodes` names blades within a chassis partition and a tenant can span them. **rSeries** is an appliance with no partitions or blades, and `vcpu-cores-per-node` must be a multiple of four. A valid two-vCPU VELOS tenant **will not commit on an rSeries**, and an image bundle named `ALL-VELOS` will not deploy on one either — which the tool points out from the filename alone.

## What it will not do

It cannot know how much of your platform is already allocated, so it validates a tenant against the published formula rather than against remaining capacity. Whether the blade has the memory free is a question for the platform.

## Standards and references

- [F5 - VELOS systems administration: tenant management, including the minimum-memory formula and blade capacities](https://techdocs.f5.com/en-us/velos-1-5-0/velos-systems-administration-configuration/title-tenant-management.html)
- [F5 - rSeries systems administration: tenant management, vCPU multiples and defaults](https://techdocs.f5.com/en-us/f5os-a-1-1-0/f5-rseries-systems-administration-configuration/title-tenant-management.html)
- [F5 CloudDocs - VELOS API: chassis partition tenant lifecycle](https://clouddocs.f5.com/api/velos-api/api-chassis-tenant.html)

## Related reading

- [The three states an F5OS tenant can be in](https://ronutz.com/en/learn/f5os-tenant-lifecycle.md): Configured, provisioned, deployed — and the rule that changing vCPU or memory means going backwards through them. Plus the published memory formula, and why a VELOS example will not commit on an rSeries.