# Explicador de configuração de tenant do F5OS

> Cole um bloco f5-tenants:tenants, da CLI ou do RESTCONF, e receba a leitura em texto claro: o ciclo de vida configured / provisioned / deployed e o que cada estado significa, a imagem e a plataforma a que ela pertence, blades e VLANs, e a alocação de memória conferida contra o mínimo publicado pela F5 de (3,5 × 1024 × vCPU) + 512. Local e offline.

- Tool: https://ronutz.com/pt-BR/tools/f5os-tenant-config-explainer
- Family: Operações e fieldcraft

---

## O que faz

Cole um bloco `f5-tenants:tenants` — a forma da CLI ou o JSON do RESTCONF — e a ferramenta o lê de volta: o estado do ciclo de vida e o que significa, a imagem e a qual plataforma ela pertence, as blades e VLANs, e cada campo explicado. Local e offline; analisa o texto e não contata plataforma alguma.

## A verificação que a torna mais que um glossário

A F5 publica a memória mínima como **(3,5 × 1024 × vCPU) + 512**, então dois vCPUs precisam de 7680 MB e quatro precisam de 14848 MB. A ferramenta calcula esse mínimo e **o mostra ao lado do valor configurado**, avisando quando a alocação está abaixo dele.

Ela também avisa quando aparece uma contagem de vCPU sem valor de memória, porque **os dois andam juntos**: aumentar cores sozinho deixa o tenant abaixo do novo mínimo.

## A regra de ciclo de vida que ela declara

**Para mudar vCPU ou memória num tenant deployed é preciso voltá-lo para `provisioned` primeiro**, fazer a mudança e devolvê-lo a `deployed`. Não é operação em produção, e a ferramenta diz isso em todo tenant deployed em vez de esperar ser perguntada.

## Formato de plataforma

Ela sinaliza o que pertence a qual máquina. **VELOS** é um chassi — `nodes` nomeia blades dentro de uma chassis partition e um tenant pode se estender por elas. **rSeries** é um appliance sem partitions nem blades, e o `vcpu-cores-per-node` precisa ser múltiplo de quatro. Um tenant VELOS válido de dois vCPUs **não vai commitar num rSeries**, e um bundle de imagem chamado `ALL-VELOS` também não vai fazer deploy nele — o que a ferramenta aponta só pelo nome do arquivo.

## O que ela não faz

Não tem como saber quanto da sua plataforma já está alocado, então valida um tenant contra a fórmula publicada e não contra a capacidade restante. Se a blade tem a memória livre é pergunta para a plataforma.

## 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

- [Os três estados em que um tenant do F5OS pode estar](https://ronutz.com/pt-BR/learn/f5os-tenant-lifecycle.md): Configured, provisioned, deployed — e a regra de que mudar vCPU ou memória significa voltar por eles. Além da fórmula de memória publicada, e por que um exemplo de VELOS não vai commitar num rSeries.