Dicionário de códigosCode dictionary

Cada falha tem um número DX-CDNN que não muda de significado: o milhar é a classe (o que fazer a seguir), a centena o domínio (onde aconteceu), e os dois últimos a falha; 00 é a própria classe. A CLI imprime-o na linha de erro — error[DX-4501] no such VM: dev — e delonix explain DX-4501 diz o resto. Decidido no ADR-0043.

Every failure has a DX-CDNN number that never changes meaning: the thousands digit is the class (what to do next), the hundreds the domain (where it happened), and the last two the failure; 00 is the class itself. The CLI prints it on the error line — error[DX-4501] no such VM: dev — and delonix explain DX-4501 says the rest. Decided in ADR-0043.

Código	Classe	Domínio	Saída	Mensagem, significado, o que fazer
`DX-0000`	sucesso	motor	0	sucesso O comando fez o que lhe foi pedido. Nada.
`DX-1000`	argumento inválido	motor	1	argumento inválido Um argumento, o valor de uma flag ou um campo do manifesto não é aceitável. A mensagem diz qual. Corrige o argumento que a mensagem nomeia e corre o comando outra vez.
`DX-1101`	argumento inválido	container	1	nome de container ambíguo O nome existe em mais de um namespace, por isso não diz qual é o container. Qualifica-o como <namespace>/<nome>.
`DX-1102`	argumento inválido	container	1	limite de memória inválido O valor de --memory, ou um resources.limits.memory do Kubernetes, não é uma contagem de bytes que este motor entenda. Usa bytes (67108864) ou um sufixo (64M, 64Mi, 1G, 1Gi).
`DX-1103`	argumento inválido	container	1	limite de CPU inválido O valor de --cpus, ou um resources.limits.cpu do Kubernetes, não é um número de núcleos que este motor entenda. Usa um número decimal de núcleos (0.5, 2); millicores (500m) são uma grafia do Kubernetes que esta flag não aceita.
`DX-1104`	argumento inválido	container	1	peso de cgroup inválido Um valor de peso (--cpu-weight, --io-weight) está fora do intervalo do cgroup v2. Passa um peso entre 1 e 10000.
`DX-1105`	argumento inválido	container	1	conjunto de CPU inválido O valor de --cpuset não se interpreta como uma lista de CPUs (ex.: 0-3,6). Passa uma lista de números ou intervalos de CPU separados por vírgulas.
`DX-1106`	argumento inválido	container	1	argumento de comando inválido Um argumento do comando ou do entrypoint contém um byte NUL, que não pode ser passado ao execve. Remove o byte NUL embutido no argumento que a mensagem nomeia.
`DX-1107`	argumento inválido	container	1	comando vazio O container não tem comando para correr: nem o ENTRYPOINT/CMD da imagem nem um comando explícito foram dados. Passa um comando, ou usa uma imagem com ENTRYPOINT ou CMD.
`DX-1108`	argumento inválido	container	1	sem processos no container Uma operação que precisa de pelo menos um processo vivo (renice) não encontrou nenhum. Verifica que o container está mesmo a correr (`delonix container ps`).
`DX-1109`	argumento inválido	container	1	caminho de montagem ao vivo inseguro Um destino de container update --volume-add/--volume-rm é recusado pela mesma verificação de segurança de caminho que os bind mounts usam. Usa um caminho de destino que fique dentro do próprio rootfs do container.
`DX-1110`	argumento inválido	container	1	origem da montagem ao vivo não existe O caminho do host dado a um bind-mount ao vivo (container update --volume-add) não existe. Verifica que o caminho de origem existe no host antes de o montar ao vivo.
`DX-1111`	argumento inválido	container	1	o container partilha a namespace de montagem do host Foi pedida uma montagem/desmontagem ao vivo a um container sem namespace de montagem própria para mudar. Este container não aceita uma mudança de volume ao vivo; pára-o e recria-o se for preciso uma.
`DX-1112`	argumento inválido	container	1	montagem ao vivo falhou O auxiliar bifurcado que faz a montagem ao vivo dentro das namespaces do container a correr saiu com falha, ou foi interrompido. Lê o código de saída na mensagem; repete o volume-add, ou reinicia o container.
`DX-1113`	argumento inválido	container	1	desmontagem ao vivo falhou O auxiliar bifurcado que faz a desmontagem ao vivo dentro das namespaces do container a correr não teve sucesso. Repete o volume-rm, ou reinicia o container.
`DX-1114`	argumento inválido	container	1	nome de dispositivo CDI inválido Um valor de --device que nomeia um dispositivo qualificado CDI não é vendor.com/class=name. Usa a forma vendor.com/class=name (ex.: nvidia.com/gpu=0).
`DX-1115`	argumento inválido	container	1	colocação no cgroup do kubelet exige o motor como root Colocar um container na hierarquia de cgroup que um RunPodSandbox do CRI nomeia exige privilégios que o rootless, ou um processo já dentro de uma namespace, não tem. Corre o servidor CRI como root, ou não peças um cgroup parent do kube em rootless.
`DX-1116`	argumento inválido	container	1	grupo de cgroup inválido O container nomeia um grupo de cgroup (`cgroup_parent`) cujo nome não é um único segmento de caminho seguro ([a-z0-9._-], no máximo 64 bytes, nem `.`/`..`, sem começar por `-`), ou cujo tecto agregado de memória, CPU ou processos não se lê. Nada é colocado: um nome que podia sair da base do motor, ou um tecto que o kernel não receberia, é recusado em vez de descartado. Usa um nome de grupo feito de [a-z0-9._-]; dá a memória em bytes ou com sufixo (1G, 512Mi), o CPU como número decimal de cores (0.5, 2) e os processos como número inteiro ou `max`.
`DX-1201`	argumento inválido	volume	1	nome de volume inválido O nome de um volume só pode ter letras, dígitos, ponto, hífen e sublinhado, e não pode começar por ponto. Escolhe um nome feito de [A-Za-z0-9._-] que não comece por ponto.
`DX-1202`	argumento inválido	volume	1	volume de rede sem dispositivo Foi pedido um volume nfs, cifs ou webdav sem a partilha a montar. Indica a partilha: --opt server=<host> --opt share=<caminho>.
`DX-1203`	argumento inválido	volume	1	registo de volume de rede sem dispositivo Um volume de rede está registado mas o registo perdeu o dispositivo a montar. Recria o volume com o seu servidor e partilha.
`DX-1204`	argumento inválido	volume	1	nome de snapshot inválido O nome de um snapshot só pode ter letras, dígitos, ponto, hífen e sublinhado, sem barra nem ponto duplo. Escolhe um nome feito de [A-Za-z0-9._-].
`DX-1205`	argumento inválido	volume	1	quota rígida num volume com dados Uma quota rígida (loopback) só pode ser posta num volume vazio: esconderia os dados que já lá estão. Cria o volume com --quota, ou esvazia-o primeiro.
`DX-1206`	argumento inválido	volume	1	quota abaixo da utilização actual A nova quota é menor do que o que o volume já guarda. Liberta espaço no volume primeiro, ou pede uma quota maior.
`DX-1207`	argumento inválido	volume	1	volume em uso Reduzir uma quota exige o volume desmontado, e há um container a usá-lo. Pára os containers que o montam e depois muda a quota.
`DX-1208`	argumento inválido	volume	1	nome de volume ambíguo O nome é ao mesmo tempo um volume no namespace do workload e um volume global. Muda o nome de um dos dois.
`DX-1209`	argumento inválido	volume	1	especificação de volume inválida Um valor de -v não tem a forma origem:/destino[:opções]. Escreve-o como origem:/destino, opcionalmente com :ro.
`DX-1210`	argumento inválido	volume	1	opção de bind não suportada O terceiro campo de -v nomeia uma opção que este motor não implementa (SELinux :z/:Z, :U). Usa :ro, :rw ou uma opção de propagação (:rprivate, :rslave, :rshared).
`DX-1211`	argumento inválido	volume	1	o destino da montagem não é absoluto O caminho dentro do container tem de começar por barra. Escreve o destino como caminho absoluto, por exemplo /data.
`DX-1212`	argumento inválido	volume	1	quota abaixo do mínimo do TrueNAS O TrueNAS recusa uma quota abaixo de 1 GiB num dataset; pedir menos não arredonda para cima, é recusado. Pede pelo menos 1 GiB, ou tira a quota para deixar o dataset sem limite.
`DX-1213`	argumento inválido	volume	1	url do TrueNAS inválido O url do alvo de provisionamento não tem esquema, tem um esquema não suportado, ou não nomeia um host. Escreve-o como https://<host>[:porto], sem caminho.
`DX-1214`	argumento inválido	volume	1	credencial no url do TrueNAS O url leva um utilizador ou password (userinfo), uma credencial escondida no manifesto em vez de um kind: Secret. Tira o userinfo e passa a credencial como apiKeySecret ou passwordSecret.
`DX-1215`	argumento inválido	volume	1	credencial sobre http simples Enviar uma chave de API ou password para um alvo TrueNAS em http:// simples põe-na na rede em claro. Usa https://, com insecureTLS: true se a appliance servir o seu próprio certificado auto-assinado.
`DX-1216`	argumento inválido	volume	1	nome de dataset TrueNAS inválido Um nome de dataset ZFS tem de ser <pool>/<nome>, sem '..', sem componente vazio e sem '-' inicial. Escreve o dataset como <pool>/<nome>, por exemplo tank/projects.
`DX-1217`	argumento inválido	volume	1	o pedido de pool de armazenamento não pode ser servido como está escrito Um `kind: StoragePool`, um `spec.pool` ou um `--pool` traz algo que um pedido de pool não pode trazer: um dispositivo, um caminho ou um comando (esses são do administrador, na allowlist), um tamanho em falta ou que não se lê, ou um pool ao lado de outro suporte para o mesmo volume (ADR-0067 D2). Nomeia só o pool; dá um `size` ao volume; e mantém `pool` separado de `nfs`/`cifs`/`webdav`/`share`/`provision`/`quota`.
`DX-1218`	argumento inválido	volume	1	a allowlist de pools de armazenamento não pode ser usada A allowlist de pools de armazenamento do administrador existe e é recusada: não se lê, nomeia um campo que ninguém definiu, falta a uma entrada o que o seu driver precisa, ou o ficheiro pode ser escrito por alguém que não é o dono (ADR-0067 D3). Corrige o ficheiro que a mensagem nomeia (`/etc/delonix/storage-pools.yaml`, a não ser que DELONIX_STORAGE_POOLS_FILE diga outro) e mantém-no com modo 0644, do root ou do utilizador que corre o motor.
`DX-1219`	argumento inválido	volume	1	registo de driver de pool de armazenamento recusado Um driver de pool de armazenamento foi registado sem id. É um erro de programação no processo que o registou, não no que foi pedido. Reporta-o: a raiz de composição regista os drivers, e um deles tem o id vazio.
`DX-1220`	argumento inválido	volume	1	a utilização não pôde ser medida por completo Um directório dentro do volume não pôde ser lido (normalmente dados de subuid de um container), por isso a utilização medida é um limite inferior, não o total real — encolher com um número não verificado pode truncar dados. Corre como um utilizador que consiga ler todos os ficheiros do volume, ou verifica o tamanho real de outra forma antes de encolher.
`DX-1221`	argumento inválido	volume	1	o helper de armazenamento recusou o pedido O helper privilegiado de armazenamento leu um pedido que não serve: não se interpreta, nomeia um campo que o protocolo não tem, nomeia uma operação que o socket não aceita (criar e destruir pools são comandos do administrador, nunca pedidos pelo socket), ou traz um pool, volume, tamanho ou state root fora do que o protocolo aceita (ADR-0067 D3). Nada foi feito. Usa os comandos do próprio motor (`delonix volume create --pool`) em vez de escrever no socket do helper; um administrador cria ou destrói um pool num terminal com `delonix-storage-helper create-pool\|destroy-pool <nome>`.
`DX-1301`	argumento inválido	rede	1	chave WireGuard inválida Uma string dada como chave WireGuard não tem 44 caracteres de base64 a terminar em '='. Passa uma chave exactamente como o `wg genkey`/`wg pubkey` a produziu.
`DX-1302`	argumento inválido	rede	1	configuração CNI inválida Um ficheiro de config/conflist CNI, ou o input de um plugin construído a partir dele, não é JSON válido ou tem a forma errada. Verifica o ficheiro `.conflist`/`.conf` que a mensagem nomeia; valida-o com um linter de JSON.
`DX-1303`	argumento inválido	rede	1	não foi possível codificar o input de um plugin CNI Construir o JSON que um plugin CNI lê no stdin falhou. Verifica a entrada do plugin no conflist à procura de um valor que o JSON não consiga representar.
`DX-1304`	argumento inválido	rede	1	resultado de plugin CNI inválido O próprio stdout de um plugin CNI não fez parse como o resultado que a especificação CNI espera. Verifica que o binário do plugin que a mensagem nomeia é a versão que o conflist deste host espera.
`DX-1305`	argumento inválido	rede	1	plugin CNI não encontrado Um plugin nomeado na cadeia CNI (ou o seu `ipam.type`) não é um binário em CNI_PATH. Instala o binário do plugin que a mensagem nomeia em CNI_PATH (por omissão /opt/cni/bin).
`DX-1306`	argumento inválido	rede	1	chave de sysctl de netns inválida Uma chave de sysctl dada para aplicar dentro de uma netns não é um nome simples `net.`. Usa uma chave `net.` com pontos, como o próprio `sysctl` aceitaria.
`DX-1307`	argumento inválido	rede	1	especificação de publish inválida Uma especificação `-p`/`--publish` tem um protocolo que não é tcp/udp, uma porta não numérica, ou um endereço de host que não é um literal IPv4. Escreve-a como [hostIp:]hostPort:contPort[/tcp\|udp], por exemplo 8080:80 ou 0.0.0.0:8080:80/tcp.
`DX-1308`	argumento inválido	rede	1	intervalo de portas de publish inválido Um INTERVALO de portas `-p` tem um limite não numérico, uma porta fora de ordem/fora de alcance, ou larguras de host/container que não coincidem. Usa hostStart-hostEnd:contStart-contEnd com os dois lados da mesma largura, dentro de 1-65535.
`DX-1309`	argumento inválido	rede	1	especificação de taxa de rede inválida Um valor `--net-bps`/`--net-burst` não faz parse, é zero, ou está fora de alcance. Usa um número com um sufixo opcional k/m/g/t, por exemplo 10mbit ou 512k.
`DX-1310`	argumento inválido	rede	1	o registo da rede está corrompido Um registo do NetworkStore em disco falta um campo que o seu driver precisa (parent, subnet, vni, ou o octeto base). Remove a rede e recria-a (`delonix network rm`, depois `delonix network create`).
`DX-1311`	argumento inválido	rede	1	nome de rede reservado O nome pedido é `bridge` (a rede default implícita) ou um nome de driver reservado (`host`/`none`). Escolhe um nome diferente.
`DX-1312`	argumento inválido	rede	1	nome de rede inválido Um nome de rede só pode usar letras, dígitos, traço e underscore. Escolhe um nome feito de [A-Za-z0-9_-].
`DX-1313`	argumento inválido	rede	1	subnet de bridge não suportada Um --subnet para o driver bridge não é um 10.<intervalo-de-workload>.0.0/16 que o IPAM deste motor consiga realizar. Passa um 10.<lo>-<hi>.0.0/16 dentro do intervalo de workload, ou omite --subnet para o motor escolher um livre.
`DX-1314`	argumento inválido	rede	1	subnet inválida Um CIDR --subnet arbitrário não é um prefixo privado (RFC 1918) de um comprimento utilizável. Usa um intervalo privado (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) com um prefixo entre /8 e /28.
`DX-1315`	argumento inválido	rede	1	gateway de rede inválido Um gateway declarado está fora do prefixo da rede, ou é o endereço de rede/broadcast. Escolhe um endereço dentro do prefixo da rede que não seja o endereço de rede ou de broadcast.
`DX-1316`	argumento inválido	rede	1	octeto base /16 inválido Um octeto base /16 para uma rede bridge está fora do espaço de endereços de workload. Escolhe um octeto base dentro do intervalo de workload que este motor reporta.
`DX-1317`	argumento inválido	rede	1	sem registo para anotar A rede default implícita `bridge` não tem registo em disco, por isso não há nada para etiquetar/anotar. Anota antes uma rede de utilizador; a rede default não pode levar labels.
`DX-1318`	argumento inválido	rede	1	chave ou valor de metadados de rede inválido Uma chave de label/annotation está vazia ou contém '=' ou uma nova linha, ou o seu valor contém uma nova linha. Usa uma chave/valor sem '=' e sem nova linha.
`DX-1319`	argumento inválido	rede	1	VNI inválido O VNI de uma rede overlay não faz parse, ou está fora de 1..16777215. Passa um VNI entre 1 e 16777215.
`DX-1320`	argumento inválido	rede	1	não é uma rede overlay Foi pedida uma operação de overlay-peer a uma rede cujo driver não é `overlay`. Aponta para uma rede criada com `--driver overlay`.
`DX-1321`	argumento inválido	rede	1	peer de overlay inválido Uma especificação de peer de overlay não tem node_ip. Escreve o peer como <node_ip> ou <node_ip>=<pubkey>=<wg_ip>.
`DX-1322`	argumento inválido	rede	1	driver de rede desconhecido Um driver de `create_lan` não é nem `macvlan` nem `ipvlan`. Usa --driver macvlan ou --driver ipvlan.
`DX-1323`	argumento inválido	rede	1	NIC parent não encontrada A NIC parent de uma rede macvlan/ipvlan não existe neste host. Passa uma NIC que o `ip link` deste host realmente mostra.
`DX-1324`	argumento inválido	rede	1	subnet de macvlan/ipvlan inválida Uma subnet de macvlan/ipvlan não faz parse como um CIDR. Escreve-a como por exemplo 192.168.1.0/24.
`DX-1325`	argumento inválido	rede	1	comando de controlo do holder inválido Uma linha enviada no socket de controlo do holder não é uma que este build reconheça. Verifica que a CLI e o holder são do mesmo build; um holder antigo pode precisar de um respawn.
`DX-1326`	argumento inválido	rede	1	payload hex inválido Um payload codificado em hex no socket de controlo do holder (um conflist CNI, uma especificação de firewall) não decodifica. Isto é um erro de protocolo interno entre a CLI e o holder; verifica que são o mesmo build.
`DX-1327`	argumento inválido	rede	1	destino de FDB/overlay peer inválido Um destino de FDB ou de overlay-peer não é um endereço IP nu. Passa um endereço IPv4 simples, sem outros caracteres.
`DX-1328`	argumento inválido	rede	1	a bridge de ingress default não pode ser removida Foi feita uma tentativa de remover a bridge de ingress default, de que todos os outros caminhos de rede dependem. Remove antes uma rede de utilizador; a bridge default não é removível.
`DX-1331`	argumento inválido	rede	1	porta inválida Uma string de porta dada ao dataplane de ingress (publish/unpublish/lbset) não está entre 1..65535. Passa uma porta numérica entre 1 e 65535.
`DX-1332`	argumento inválido	rede	1	protocolo inválido Foi dado um protocolo que não tcp/udp a uma chamada de publish/unpublish. Usa tcp ou udp.
`DX-1333`	argumento inválido	rede	1	política de egress inválida Uma política de egress não é allow, deny, ou allowlist:<cidrs>. Usa allow, deny, ou allowlist:<CIDRs separados por vírgula>.
`DX-1334`	argumento inválido	rede	1	hostname de egress inválido Um sufixo de `egress host` não é um nome DNS simples. Usa um sufixo de hostname/domínio simples, por exemplo example.com.
`DX-1335`	argumento inválido	rede	1	IP fora do espaço de endereços de ingress Um IP de container/publish está fora do espaço de endereços de ingress (10.200-254.x). Liga o container a uma rede dentro do intervalo de ingress que este motor reporta.
`DX-1336`	argumento inválido	rede	1	firewall aplicada sem IP apply_firewall/apply_firewall_all foi chamado com uma lista de IPs vazia. Isto é um erro de chamada interna; reporta-o se o vires vindo da CLI.
`DX-1337`	argumento inválido	rede	1	especificação de firewall inválida Uma especificação de firewall (JSON descodificado de hex enviado ao holder) não faz parse na estrutura esperada. Verifica que a CLI e o holder são do mesmo build.
`DX-1338`	argumento inválido	rede	1	não foi possível codificar uma especificação de firewall Codificar a firewall de um container para enviar pelo socket de controlo falhou. Isto é um erro de chamada interna; reporta-o se o vires vindo da CLI.
`DX-1339`	argumento inválido	rede	1	sem prefixo de ingress livre Não sobra nenhum prefixo /16 no espaço de endereços de ingress para uma rede nova. Remove uma rede não usada (`delonix network rm`) para libertar um prefixo.
`DX-1340`	argumento inválido	rede	1	o IP não pertence à rede Um IP fixo dado para ligar um container não está dentro da subnet da rede alvo. Passa um endereço dentro da própria subnet da rede (`delonix network inspect <name>`).
`DX-1341`	argumento inválido	rede	1	registo de provedor de gateway inválido Um registo de GatewayProvider (ADR-0051) não tinha id, ou reclamou um nome que já pertence a outro provider. Corrige o registo que a mensagem descreve; isto é um erro de programação no processo que o registou, não um manifesto/flag.
`DX-1344`	argumento inválido	rede	1	registo de provider de zona de rede recusado Um processo tentou registar um SegmentProvider com id vazio, ou com um id/alias que já pertence a outro provider. Corrige o registo (erro de chamada interna, a menos que esteja envolvido um crate de provider de terceiros).
`DX-1349`	argumento inválido	rede	1	o URL do OPNsense mandaria a chave da API em claro O URL do OPNsense não é https://, não nomeia um host, ou traz userinfo (`user:pass@`). O par key/secret vai no cabeçalho Authorization de cada pedido, por isso HTTP simples entrega-o a qualquer coisa no caminho, e userinfo é uma palavra-passe na configuração com outro nome. Usa https://<host> (com `tls.insecureSkipVerify: true` ou um `caFile` para o certificado auto-assinado da appliance) e mantém a credencial em `auth`.
`DX-1360`	argumento inválido	rede	1	conjunto de VIP inválido Um conjunto de VIP (`network vip-pool set`, `DELONIX_SERVICE_VIP_CIDR`) não é um prefixo IPv4 privado (RFC 1918 ou 100.64.0.0/10) entre /16 e /29 escrito com os bits de host a zero, ou dois conjuntos sobrepõem-se (ADR-0066 D2). Indica um ou mais prefixos privados sem sobreposição, como 10.90.0.0/16.
`DX-1361`	argumento inválido	rede	1	VIP fora do conjunto O `spec.vip` de um Service não está dentro de nenhum conjunto de VIP configurado, ou é o endereço de rede, o primeiro ou o de broadcast do conjunto. Escolhe um endereço dentro do conjunto que `delonix network vip-pool show` mostra, ou tira o `spec.vip` e deixa o motor escolher.
`DX-1380`	argumento inválido	rede	1	a intenção de rede não pode ser servida como está escrita O que um documento de rede ou o providers.yaml pede não pode ser servido como está escrito: nada nomeia um provider para o papel e nada mais decide (zero ou vários registados, ou um providers.yaml sem networkDefaults.<papel>), ou o provider recusou os campos enviados (o OPNsense responde com validações campo a campo). Reason `invalid_intent` da D5 do ADR-0059. Lê a mensagem: nomeia o provider (networkDefaults.<papel> no providers.yaml, ou spec.provider onde o Kind o tem), ou corrige os campos que o provider listou.
`DX-1401`	argumento inválido	imagem	1	SBOM vazio A imagem não tem base de dados de pacotes apk ou dpkg, por isso não há nada para procurar vulnerabilidades. Analisa uma imagem construída sobre uma distribuição com gestor de pacotes, ou analisa antes a imagem base.
`DX-1402`	argumento inválido	imagem	1	base de dados de avisos inválida A base de dados de avisos que o scanner carregou não é JSON válido. Sincroniza-a outra vez com `delonix image scan --update --feed <url>`.
`DX-1403`	argumento inválido	imagem	1	o feed OSV não é JSON O feed dado ao scanner não pôde ser lido como JSON. Confirma que o URL do --feed aponta para uma exportação OSV em JSON, e não para uma página HTML.
`DX-1404`	argumento inválido	imagem	1	o feed OSV tem a forma errada O feed é JSON mas não é uma lista de avisos nem um objecto com uma lista vulns. Aponta o --feed para uma exportação OSV: uma lista de avisos, ou um objecto com uma lista vulns.
`DX-1405`	argumento inválido	imagem	1	não é um módulo Odoo O directório indicado como módulo não tem __manifest__.py. Aponta a análise para o directório do próprio módulo, o que tem o __manifest__.py.
`DX-1406`	argumento inválido	imagem	1	nenhum módulo Odoo encontrado Nenhum directório abaixo do caminho indicado tem __manifest__.py. Aponta a análise para o directório que contém os módulos.
`DX-1407`	argumento inválido	imagem	1	Dockerfile inválido O ficheiro de build não se lê, ou pede uma instrução ou flag que este motor não suporta. A mensagem diz a linha. Corrige a linha que a mensagem nomeia; o `delonix build --help` lista o que é suportado.
`DX-1408`	argumento inválido	imagem	1	arquivo de imagem inválido O arquivo a carregar está incompleto ou corrompido: falta o manifesto, ou um blob não corresponde ao seu hash. Exporta o arquivo outra vez a partir da origem e carrega o ficheiro novo.
`DX-1409`	argumento inválido	imagem	1	não foi possível empacotar ou desempacotar uma layer A leitura, compressão ou extracção de uma layer ou de um rootfs falhou. A mensagem traz o erro de origem. Lê o erro na mensagem; verifica o espaço livre do state root (`delonix system df`) e tenta outra vez.
`DX-1410`	argumento inválido	imagem	1	imagem sem layers O registo da imagem não tem layers para montar como rootfs. Descarrega ou constrói a imagem outra vez.
`DX-1411`	argumento inválido	imagem	1	o state root não pode suportar um overlay O caminho do state root contém um carácter (':') que as opções de montagem do overlay não conseguem exprimir. Muda o state root para um caminho sem ':' (DELONIX_ROOT).
`DX-1412`	argumento inválido	imagem	1	chave de assinatura inválida Uma chave de assinatura ou verificação não é uma chave P-256 válida em PEM, ou não pôde ser gerada. Indica uma chave ECDSA P-256 em PEM compatível com o cosign.
`DX-1413`	argumento inválido	imagem	1	imagem não assinada O registo não tem assinatura cosign para o digest da imagem. Assina-a com `delonix image sign`, ou descarrega uma imagem assinada.
`DX-1414`	argumento inválido	imagem	1	assinatura inválida Existe uma assinatura, mas não verifica com a chave indicada, ou o seu manifesto ou conteúdo está malformado. Confirma que a chave é aquela com que a imagem foi assinada; não corras uma imagem cuja assinatura falha.
`DX-1415`	argumento inválido	imagem	1	estado da assinatura desconhecido O registo não respondeu à consulta da assinatura, por isso não foi possível decidir se a imagem está assinada. Não é um veredicto. Tenta outra vez quando o registo estiver acessível; a mensagem traz o erro do registo.
`DX-1416`	argumento inválido	imagem	1	imagem já assinada Já existe uma assinatura para este digest. Usa --force para a assinar outra vez.
`DX-1417`	argumento inválido	imagem	1	não foi possível assinar A produção ou o envio da assinatura falhou. Lê o erro na mensagem e verifica o login no registo (`delonix image login`).
`DX-1418`	argumento inválido	imagem	1	uma layer expande para além do limite de extracção Uma layer tem mais bytes descomprimidos ou mais entradas do que os limites de extracção permitem, por isso foi recusada enquanto era lida, antes de poder encher o disco. Um blob pequeno pode expandir para terabytes; são os limites que o impedem. Usa uma imagem mais pequena. Se a imagem é de confiança e é mesmo tão grande, aumenta DELONIX_LAYER_MAX_BYTES ou DELONIX_LAYER_MAX_ENTRIES.
`DX-1501`	argumento inválido	vm	1	não suportado neste backend O verbo pause, unpause, snapshot, restore ou delete-snapshot pedido não está implementado pelo backend desta VM. Usa um backend que o suporte (o libvirt é o que mais suporta), ou tira o verbo.
`DX-1502`	argumento inválido	vm	1	registo de backend de VM inválido Um registo de backend não tinha id, reivindicou auto-selecção vinda de fora desta crate, ou reivindicou um nome que outro backend já tem. Corrige o registo que a mensagem descreve; isto é um erro de programação no processo que o registou, não um manifesto/flag.
`DX-1503`	argumento inválido	vm	1	backend de VM desconhecido O valor de --backend/DELONIX_VM_BACKEND não nomeia um backend registado. Usa um dos backends que a mensagem lista.
`DX-1504`	argumento inválido	vm	1	o registo da VM nomeia um backend não registado O próprio registo da VM nomeia um backend para o qual este processo não tem registo. Corre um build/processo que registe esse backend, ou recria a VM com um que esteja registado aqui.
`DX-1505`	argumento inválido	vm	1	exige o backend libvirt O spec.volumes da VM precisa de virtio-9p, que o backend Cloud Hypervisor não implementa. Remove `backend: cloud-hypervisor`, ou tira os volumes.
`DX-1506`	argumento inválido	vm	1	caminho do socket da VM demasiado longo O caminho do api-socket ou do socket de consola da VM não caberia no sun_path de um socket UNIX (108 bytes em Linux). Usa um nome de VM mais curto ou um DELONIX_ROOT mais curto.
`DX-1507`	argumento inválido	vm	1	nome de VM inválido Um nome de VM só pode usar letras, dígitos, ponto, traço e underscore, sem travessia de caminho. Escolhe um nome feito de [A-Za-z0-9._-] sem '/', '..', nem '-' inicial.
`DX-1508`	argumento inválido	vm	1	namespace não aplicável neste backend O backend da VM não põe as suas VMs na SDN deste motor, por isso o isolamento de namespace não pode ser aplicado. Usa `--backend cloud-hypervisor`, ou tira `--namespace`.
`DX-1509`	argumento inválido	vm	1	--disk-size menor que a imagem base Um overlay qcow2 não pode ser menor que o seu backing file. Pede um --disk-size pelo menos tão grande como a imagem base.
`DX-1510`	argumento inválido	vm	1	nome de snapshot inválido Um nome de snapshot de VM só pode usar letras, dígitos, ponto, traço e underscore, sem travessia de caminho. Escolhe um nome feito de [A-Za-z0-9._-] sem '/', '..', nem '-' inicial.
`DX-1511`	argumento inválido	vm	1	--ip exige o modo nat do libvirt Um IP estático é materializado como uma reserva DHCP na rede libvirt, que só o modo de rede nat/network tem. Tira --net-mode, ou põe-no a nat, para usar --ip; numa bridge de host, reserva antes o IP no próprio DHCP da LAN.
`DX-1512`	argumento inválido	vm	1	IP estático inválido O valor de --ip não é interpretável como um endereço IPv4. Passa um endereço IPv4 em formato de quatro octetos.
`DX-1513`	argumento inválido	vm	1	não foi possível reservar o IP estático o virsh net-update recusou a reserva DHCP para este par MAC/IP. Lê a razão do virsh na mensagem; o IP pode estar fora da subnet da rede.
`DX-1514`	argumento inválido	vm	1	o backup de disco a quente exige o backend libvirt Um backup de disco a quente (VM a correr) usa o virsh blockcommit, que só o backend libvirt tem. Pára a VM e tira antes um snapshot offline, ou recria-a no backend libvirt.
`DX-1515`	argumento inválido	vm	1	VM não está no estado certo para este verbo pause precisa de uma VM a correr e unpause precisa de uma em pausa; a VM não está em nenhum dos dois estados. Consulta `delonix vm status <nome>` e usa o verbo que corresponde ao seu estado actual.
`DX-1516`	argumento inválido	vm	1	não foi possível copiar o user-data do cloud-init O ficheiro que um --user-data nomeia não pôde ser copiado para o directório de seed da VM. Verifica que o caminho existe e é legível por este utilizador.
`DX-1517`	argumento inválido	vm	1	não existe esse nó Proxmox O nó nomeado no alvo não faz parte do cluster a que este url responde. Aponta o alvo a um nó que o `GET /nodes` deste cluster realmente reporta, ou corrige o url.
`DX-1518`	argumento inválido	vm	1	url do Proxmox inválido O url do alvo não tem esquema, tem um esquema que não https, ou não nomeia um host. Escreve-o como https://<host>:8006, sem caminho.
`DX-1519`	argumento inválido	vm	1	credencial no url do Proxmox O url leva um utilizador ou password (userinfo), uma credencial escondida no manifesto em vez de um kind: Secret. Tira o userinfo e passa a credencial como um token de API ou password do Proxmox num Secret.
`DX-1520`	argumento inválido	vm	1	nome de bridge Proxmox inválido Um nome de bridge é interpolado na propriedade net0 da VM, e tem de ser um nome de interface Linux válido. Usa um nome como vmbr0: letras, dígitos, '-', '_' ou '.', até 15 caracteres.
`DX-1521`	argumento inválido	vm	1	nome de nó Proxmox inválido Um nome de nó entra num caminho de URL em cada chamada, e tem de ser o que o próprio Proxmox aceita. Usa letras, dígitos, '-' e '.', a bater com o nome do nó em `pvecm status`.
`DX-1522`	argumento inválido	vm	1	spec de disco Proxmox inválida O disco de uma VM neste backend tem de nomear um template a clonar ou um storage e tamanho no nó; um caminho local não tem significado ali. Escreve `template:<vmid>` para clonar um template, ou `<storage>:<tamanho-em-GiB>` para um disco novo, por exemplo local-lvm:8.
`DX-1523`	argumento inválido	vm	1	nome de instantâneo Proxmox inválido Um nome de instantâneo entra num caminho de URL e no próprio espaço de nomes do Proxmox, e 'current' está reservado para o estado ao vivo. Usa letras, dígitos, '-' e '_', e não 'current'.
`DX-1524`	argumento inválido	vm	1	campo não suportado no backend Proxmox O manifesto pede um kernel/initrd/seed/dispositivo local, um ajuste do QEMU que pertence ao nó, ou uma escapatória exclusiva do libvirt — nada disto este backend remoto consegue honrar. Tira o campo que a mensagem nomeia, ou usa um backend local (`--backend libvirt`).
`DX-1525`	argumento inválido	vm	1	VM sem handle do Proxmox O registo da VM não leva handle do Proxmox, por isso não foi criada por este backend e este backend não sabe o seu vmid. Gere esta VM com o backend que a criou.
`DX-1526`	argumento inválido	vm	1	o Proxmox rejeitou o pedido O nó respondeu HTTP 400/422: um parâmetro do pedido não é aceitável para ele; a mensagem traz a razão do próprio nó. Lê a razão do nó na mensagem e corrige o campo que ela nomeia.
`DX-1527`	argumento inválido	vm	1	capacidade desconhecida Uma entrada de `required_capabilities` (`vm create --require`, `spec.requiredCapabilities`) nomeia algo que o catálogo de capacidades não tem — um erro de escrita, ou um nome de outra versão do catálogo. É recusada antes de qualquer backend ser consultado. Usa um nome de `delonix provider ls` (a versão do catálogo está no cabeçalho).
`DX-1528`	argumento inválido	vm	1	regra de firewall do Proxmox inválida Uma regra da firewall PRÓPRIA do nó (não a firewall SDN deste motor) nomeou um `type` diferente de 'in'/'out', ou uma `action` diferente de ACCEPT/DROP/REJECT — o nome de um grupo de firewall é outro tipo de valor que este cliente não valida nem aceita. Usa 'in' ou 'out' para o type, e ACCEPT, DROP ou REJECT para a action.
`DX-1529`	argumento inválido	vm	1	tipo de dump de cloud-init Proxmox inválido o `type` de cloudinit_dump tem de ser um dos três que a rota de cloud-init do nó aceita, e é recusado aqui antes de qualquer pedido chegar ao nó. Pede 'user', 'network' ou 'meta'.
`DX-1530`	argumento inválido	vm	1	id de zona ou vnet SDN do Proxmox inválido Um id de zona ou vnet entra num caminho de URL e no próprio espaço de nomes SDN do nó, que o Proxmox limita a uma letra minúscula seguida de até 7 letras minúsculas ou dígitos (8 caracteres no total). Escolhe um id de até 8 caracteres, começado por uma letra minúscula, o resto letras minúsculas ou dígitos.
`DX-1531`	argumento inválido	vm	1	nome de alias/ipset da firewall do Proxmox inválido Um nome de alias ou de IP-set da firewall PRÓPRIA da VM (não a firewall SDN deste motor) vai para um caminho de URL e para o namespace do próprio nó, que o Proxmox limita a uma letra seguida de uma ou mais letras, dígitos, '-' ou '_' (pelo menos 2 caracteres no total). Escolhe um nome que comece por uma letra e tenha pelo menos mais uma letra, dígito, '-' ou '_' a seguir.
`DX-1532`	argumento inválido	vm	1	endereço de firewall do Proxmox inválido Um CIDR/endereço dado a um alias de firewall ou a uma entrada de um IP-set nomeado não é um endereço IPv4/IPv6, opcionalmente com um '/<prefixo>' — as rotas de alias/ipset do próprio nó rejeitam-no antes de mais nada. Dá um endereço IPv4 ou IPv6, ou um intervalo CIDR como '10.0.0.0/8'.
`DX-1533`	argumento inválido	vm	1	CIDR de subnet SDN do Proxmox inválido Uma subnet SDN é nomeada por uma rede CIDR (um endereço IPv4 ou IPv6 com um comprimento de prefixo), recusada aqui antes de entrar no corpo de um pedido ou, com o `/` trocado por `-`, num caminho de URL. Dá um CIDR como '10.0.0.0/24' ou 'fd00::/64', com um comprimento de prefixo válido para a família de endereços.
`DX-1534`	argumento inválido	vm	1	endereço SDN do Proxmox inválido Um endereço IPv4/IPv6 simples (uma ponta de intervalo DHCP, um servidor DNS, uma reserva no IPAM, o endereço de router de um nó de fabric) ou um endereço MAC que um campo SDN recebe não foi reconhecido como tal, recusado antes de entrar no corpo de um pedido ou num URL. Dá o endereço sem comprimento de prefixo ('10.0.0.50', 'fd00::5'), ou o MAC como XX:XX:XX:XX:XX:XX.
`DX-1535`	argumento inválido	vm	1	tempo limite de encerramento do Proxmox inválido Pediu-se a um encerramento ou reinício feito pelo convidado que esperasse mais do que este cliente espera por qualquer tarefa do nó, por isso o cliente desistiria com o nó ainda dentro da tarefa. Dá um tempo limite menor do que o prazo de tarefa do cliente (600 segundos por omissão), ou omite-o para ficar com o valor por omissão do próprio nó.
`DX-1536`	argumento inválido	vm	1	redimensionamento de VM inválido O `vm resize` precisa de `--vcpus` e/ou `--memory`; os vCPUs têm de ser pelo menos 1 e a memória um número com sufixo M/G opcional (`512M`, `4G`, `4Gi`). Um valor que não se lê é recusado em vez de ser tomado por um valor por omissão. Passa `--vcpus <n>` (n ≥ 1) e/ou `--memory <tamanho>`, por exemplo `--memory 4G`.
`DX-1537`	argumento inválido	vm	1	alteração de cloud-init inválida O `vm cloud-init` precisa de `--hostname`, `--user` e/ou `--ssh-key`; o hostname tem de ser uma etiqueta DNS (letras, dígitos, '-', no máximo 63), o utilizador um nome de login, cada chave uma linha. Uma imagem de appliance não corre cloud-init e é recusada. Dá pelo menos um dos três, na forma que o convidado aceita — por exemplo `--hostname web-1 --ssh-key @~/.ssh/id_ed25519.pub`.
`DX-1538`	argumento inválido	vm	1	nó inválido para onde mover a VM O `vm move --node` nomeia o nó do cluster da VM para onde ela vai. Esse nome tem de ser um membro do cluster, estar online e não ser o nó onde a VM já está; o motor nunca escolhe um por ti. Passa outro membro do cluster que esteja online — a lista do próprio nó é `pvecm nodes`, ou `delonix provider describe proxmox --probe`.
`DX-1539`	argumento inválido	vm	1	não foi possível ler a imagem local Uma VM Proxmox criada a partir de uma imagem do store do motor é primeiro enviada para o nó (ADR-0057). O ficheiro para onde a imagem aponta não pôde ser aberto nem lido, ou está vazio. Verifica a imagem com `delonix vm image ls` e `delonix vm image describe <nome>`; volta a descarregá-la ou a construí-la se o ficheiro faltar.
`DX-1540`	argumento inválido	vm	1	o container de sistema pede algo que o nó não consegue guardar Um container de sistema num nó Proxmox é sempre sem privilégio: um privilegiado seria uma decisão de privilégio num host remoto, com spike próprio (ADR-0058). O seu entrypoint é guardado como uma linha partida pelos espaços, por isso um argumento com um espaço ou um carácter de controlo não pode ficar como foi escrito; o seu ambiente é uma lista de NOME=valor, em que o nome tem letras, dígitos e underscores. Deixa o `unprivileged` a true, escreve o entrypoint como argumentos sem espaços (ou põe-no num script dentro da imagem), e nomeia cada variável só com letras, dígitos e underscores.
`DX-1550`	argumento inválido	vm	1	controlador, prefix list ou route map do SDN do Proxmox inválido Um controlador BGP/EVPN, uma prefix list ou um route map do SDN do próprio cluster (não o deste motor) foi recusado antes de qualquer pedido: um id fora do formato do próprio Proxmox (um id de controlador começa por uma letra; um id de prefix list ou de route map tem de 1 a 32 letras, dígitos, '-' ou '_', e o nó reserva alguns), um campo em falta que o tipo de controlador exige (EVPN: um ASN e exactamente um de peers/fabric; BGP: um nó, um ASN e peers), ou um campo de entrada que o nó não aceitaria (acção que não seja permit/deny, um comprimento de prefixo além da família de endereços, uma chave de match/set desconhecida). Corrige o campo que a mensagem nomeia; o `apidoc.js` do próprio nó lista os formatos.
`DX-1552`	argumento inválido	vm	1	a firewall de vnet do Proxmox não é escrita por este motor Uma escrita na firewall própria de uma vnet do Proxmox — as opções, uma regra nova ou uma regra alterada — é recusada antes de qualquer pedido, sejam quais forem os campos. Se uma regra de vnet filtra alguma coisa é decidido nó a nó pela opção `nftables` da firewall do host, em `/nodes/{node}/firewall`, que este motor não lê (ADR-0049 D3: administração do host); com a firewall iptables por omissão, o nó guarda a regra e não filtra nada. Uma escrita que poderia ser reportada como uma protecção que não existe é recusada em vez disso. Mesmo onde é aplicada, uma regra de vnet filtra o tráfego em bridge entre convidados dessa vnet, não o tráfego encaminhado entre vnets. Para o tráfego de ou para um convidado, usa a firewall dele (`NetworkPolicy` com `scope: vm` ou `scope: systemcontainer`). Escrever a firewall de uma vnet exige uma decisão do dono para ler primeiro as opções de firewall do nó (um adendo ao ADR-0049).
`DX-1601`	argumento inválido	stack	1	fonte GitOps inválida Uma `kind: GitOpsSource` foi recusada antes de se obter seja o que for (ADR-0021): um URL que não é file:///, https:// nem ssh:// (ou que leva credenciais, ou que se lê como opção), uma ref que não é refs/heads/<n> nem refs/tags/<n>, um caminho que sai do repositório, um intervalo fora de 15s–24h, uma fonte ssh:// sem chave e sem chaves de host fixadas, commits assinados sem chaves de confiança, uma política de segurança que nomeia uma acção ou um Kind que não pode, ou um segredo referido que não existe no nó. Corrige o campo que a mensagem nomeia. As credenciais nomeiam-se (`secretRef`, `knownHostsRef`, `trustedKeysRef`) e criam-se primeiro no nó, nunca vêm no URL nem no repositório.
`DX-1602`	argumento inválido	stack	1	o commit foi recusado — nada foi aplicado Uma passagem de uma fonte GitOps leu o commit e recusou-o antes de aplicar seja o que for: o caminho está vazio ou não existe, há debaixo dele um symlink, um submódulo, um ponteiro LFS ou material de chave privada, o YAML não carrega, um documento é recusado pela guarda das fontes pull (um Kind que uma fonte nunca aplica, acesso ao host, a credencial da própria fonte, outra fonte, um namespace que não é o da fonte), ou o grafo ou o plano falham. A stack em execução fica intacta. Lê as linhas que a passagem imprimiu acima do erro, ou `delonix gitops status`, corrige o repositório e empurra um commit novo — a próxima passagem apanha-o.
`DX-1603`	argumento inválido	stack	1	a fonte passa um limite do que uma passagem lê Uma passagem recusa o que não limitaria: mais de 4096 entradas debaixo do caminho, mais de 256 ficheiros de manifesto, um ficheiro de manifesto acima de 1 MiB ou 8 MiB ao todo, uma resposta do git maior que o seu tecto, ou um repositório obtido acima de 256 MiB (o espelho é então removido). Aponta `spec.source.path` para o directório que tem os manifestos, e mantém os ficheiros grandes fora dele.
`DX-1604`	argumento inválido	stack	1	o plano traz uma acção que a política de segurança bloqueia — nada foi aplicado O commit planeou uma acção que o `spec.safety` da fonte não permite: `Adopt`, `Replace` ou `Reboot` fora de `allow`, um `Conflict` com outra stack, ou mais remoções do que `maximumDeletes`. Uma passagem aplica o plano inteiro ou nada dele. Se a acção é desejada, permite-a no nó (`spec.safety.allow`, `prune`, `maximumDeletes`) e aplica a fonte; senão, reverte o commit.
`DX-1701`	argumento inválido	cluster	1	CNI de cluster desconhecida O `spec.cni` (ou `--cni`) nomeia a rede dos pods que o motor instala nos nós do cluster. Os valores que existem são `default` (a do próprio motor: kindnet no modo kind, uma bridge local ao nó num cluster kubeadm de um só nó), `none` (não instala nada; o operador aplica a sua) e os perfis seleccionáveis `cilium`, `calico` e `flannel`, cada um fixado a uma versão e ao digest do artefacto. Qualquer outro valor não instalava nada nem o dizia, o que deixa todos os nós `NotReady`. Usa um de `default`, `none`, `cilium`, `calico`, `flannel`. O `delonix cluster network profiles` imprime cada um com a versão fixada e o nível de suporte; para correr uma CNI que este motor não traz, usa `none` e aplica o manifesto dela depois de o cluster estar de pé.
`DX-1702`	argumento inválido	cluster	1	uma opção de rede que o perfil escolhido não lê Um campo de `spec.network` foi posto a algo que o perfil de rede escolhido não renderiza: um `dataplane` fora dos modos do perfil, um modo de `kubeProxy` que ele não implementa, uma extensão (`hubble`, `multus`) que precisa de outra CNI principal ou de uma combinação que nunca foi medida, um nome de interface fora do limite do próprio kernel, ou qualquer botão em `cni: default`/`cni: none`, que não instalam add-on nenhum e o ignorariam. Os dataplanes encaminhados (`native`, BGP) estão ausentes de propósito: exigem que a rede em volta do cluster transporte as rotas dos pods, o que este motor não configura e não vai assumir. A mensagem nomeia o campo e lista os valores que o perfil aceita. Remove o campo, ou escolhe um perfil que o leia.
`DX-1703`	argumento inválido	cluster	1	a MTU dos pods não cabe no encapsulamento O `spec.network.mtu` está fora do intervalo 1280-9000, ou não deixa espaço para o encapsulamento escolhido na MTU do próprio nó (VXLAN e Geneve levam 50 bytes, IP-in-IP 20). Uma MTU que não cabe não falha: o dataplane sobe e descarta em silêncio os pacotes grandes, o que se lê como lentidão inexplicada e não como erro — a mesma armadilha que o `docs/guia-rede.md` já registra para o overlay cifrado deste motor. Omite o `spec.network.mtu` e deixa o bootstrap calculá-lo a partir da MTU do nó e do encapsulamento, ou põe-no no máximo em `nodeMtu` menos o overhead que a mensagem nomeia. Se os nós não correm a 1500, declara o valor real em `spec.network.nodeMtu`.
`DX-1704`	argumento inválido	cluster	1	os CIDR do cluster entram em conflito entre si ou com o ambiente O `spec.podSubnet` e o `spec.serviceSubnet` sobrepõem-se, ou um deles sobrepõe-se a uma rede que este host já usa, ou o CIDR dos pods é pequeno demais para o número de nós (o controller-manager corta um /24 por nó, por isso os nós seguintes não receberiam gama nenhuma e os pods deles ficariam Pending). Um campo CIDR pode também trazer bits fora do seu próprio prefixo (`10.244.0.1/16`), e isso é recusado em vez de mascarado, para que o manifesto e o cluster não possam discordar sobre o que foi pedido. Até este código existir, os campos CIDR eram validados só por CONJUNTO DE CARACTERES — `9`, `1.2.3.4` e `0.0.0.0/99` passavam todos, e a falha chegava mais tarde, do `kubeadm`, num host. Escolhe gamas que não se sobreponham entre si nem às redes do próprio host (o `delonix network ls` mostra-as), e alarga o CIDR dos pods para pelo menos 256 endereços por nó. Nada é criado quando isto é recusado.
`DX-1705`	argumento inválido	cluster	1	o perfil de rede escolhido é experimental O perfil está implementado e o artefacto dele está fixado e verificado, mas NÃO foi validado de ponta a ponta contra o CRI deste motor numa topologia de vários nós — a própria secção «o que não foi medido» do ADR-0074 di-lo por escrito. Activá-lo por omissão seria a falha «diz que sim sobre trabalho que não fez» que este projecto recusa, por isso fica atrás de um consentimento explícito em vez de ser escondido ou removido. Para o usar mesmo assim, di-lo no manifesto (`spec.network.experimental: true`) ou na linha de comandos (`--experimental-cni`), e lê o `docs/network-compatibility.md` para saber exactamente o que foi e o que não foi medido. A recusa nomeia a razão desse perfil em concreto.
`DX-1706`	argumento inválido	cluster	1	uma capacidade de rede que o caminho do cluster ainda não implementa O manifesto pediu algo que este bootstrap ainda não faz — hoje é qualquer `spec.network.ipFamily` que não seja `ipv4`: o caminho do cluster renderiza só CIDR IPv4 de pods e de serviços, e a validação de CIDR dele é aritmética IPv4. Isto é «não implementado», não «impossível»: o ADR-0065 leva o dataplane IPv6 e o trabalho é real, só não chegou a este caminho. Deixa o `spec.network.ipFamily` sem valor (ou `ipv4`). Para um cluster dual-stack hoje, faz o bootstrap com `cni: none` e aplica a tua CNI com a configuração dual-stack dela.
`DX-1707`	argumento inválido	cluster	1	um campo da config kind que este motor não honra Uma config `kind.x-k8s.io/v1alpha4` (`delonix cluster create --config`, ou `cluster apply` de um documento desses) é aceite campo a campo: o delonix honra o que consegue implementar nativamente (`nodes[].role`, `name`, `networking.podSubnet`, `networking.serviceSubnet`, `networking.apiServerPort`, `networking.disableDefaultCNI`) e recusa o resto PELO NOME em vez de avisar e ignorar — um campo que se lê como aplicado e não foi é a falha-silenciosa que este motor não entrega. O conjunto recusado é o que não tem equivalente no modo kind nativo do delonix: `extraMounts`/`extraPortMappings` de nó (os nós não são contentores Docker com a canalização de portas/volumes do kind), `kubeadmConfigPatches`/`kubeadmConfigPatchesJSON6902` e `containerdConfigPatches*` (o delonix escreve a sua própria config rootless de kubeadm/containerd), `featureGates`, `runtimeConfig`, e os botões de `networking` que ele não renderiza (`kubeProxyMode`, `apiServerAddress` que não seja loopback, `ipFamily` que não seja `ipv4`). Uma chave não reconhecida (um erro de escrita) é recusada da mesma forma. Remove o campo nomeado da config, ou passa às flags de `delonix cluster create` para o que o delonix suporta. Para uma capacidade que o delonix não implementa, cria o cluster com `networking.disableDefaultCNI: true` (ou `--cni none`) e aplica a tua própria configuração depois de ele estar de pé. Nada é criado quando isto é recusado.
`DX-1801`	argumento inválido	segurança	1	nome de segredo inválido O nome de um segredo só pode ter minúsculas, dígitos, ponto, hífen e sublinhado, até 64 caracteres. Escolhe um nome feito de [a-z0-9._-].
`DX-1802`	argumento inválido	segurança	1	chave de segredo inválida A chave de um segredo tem de ser um nome de variável de ambiente válido: uma letra ou sublinhado, seguidos de letras, dígitos ou sublinhados. Muda o nome da chave, por exemplo DB_PASSWORD.
`DX-1803`	argumento inválido	segurança	1	nome de credencial inválido O nome de uma credencial só pode ter minúsculas, dígitos, ponto, hífen, sublinhado e dois pontos. Escolhe um nome feito de [a-z0-9._:-].
`DX-1804`	argumento inválido	segurança	1	chave mestra corrompida O ficheiro da chave mestra do host tem o tamanho errado, por isso nada do que foi cifrado com ela pode ser lido. Repõe a chave a partir de um snapshot do nó (`delonix system snapshot restore`); sem ela os segredos cifrados perdem-se.
`DX-1805`	argumento inválido	segurança	1	o cofre de segredos não conseguiu cifrar ou decifrar A cifra ou a decifra falhou: um blob corrompido, ou uma chave que não é aquela com que foi selado. Confirma que a chave mestra é a do próprio host; recria o segredo se o ficheiro estiver corrompido.
`DX-1901`	argumento inválido	máquina	1	perfil AppArmor indisponível O perfil AppArmor pedido não pôde ser carregado: o AppArmor não está activado neste host, o apparmor_parser não está no PATH, ou recusou o perfil. Activa o AppArmor neste host, instala o apparmor_parser, ou passa --security-opt apparmor=unconfined.
`DX-1902`	argumento inválido	máquina	1	nenhum spec CDI encontrado Um pedido --gpus/--device nomeou um dispositivo qualificado CDI, mas este host não tem spec CDI gerado nenhum. Gera um com `nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml` (instalando primeiro o nvidia-container-toolkit se for preciso).
`DX-1903`	argumento inválido	máquina	1	o socket passado pelo gestor de serviços não pode ser servido A API de nó foi arrancada por activação de socket (o `LISTEN_PID` nomeia-a) e o que lhe foi passado não é um socket unix de stream à escuta: o `LISTEN_FDS` não se lê como uma contagem, foi passado mais de um socket, ou o descritor é uma porta TCP, um socket de datagramas ou uma ligação em vez de um socket à escuta. Servi-lo na mesma perderia as garantias do socket local e do `SO_PEERCRED`, ou serviria um socket que ninguém pediu. Corrige a unit `.socket`: um só `ListenStream=` com um caminho absoluto, `Accept=no`, `SocketMode=0600`. O `delonix serve node-api --install-units` escreve um par correcto.
`DX-1904`	argumento inválido	máquina	1	foi dado --addr a uma API de nó arrancada por activação de socket O gestor de serviços passou um socket à escuta e a linha de comandos também nomeia um com `--addr`. São dois sockets diferentes; servir um deles em silêncio deixaria os clientes do outro sem resposta. Tira o `--addr` do `ExecStart=` da unit: com activação de socket o endereço é o `ListenStream=` da unit `.socket`.
`DX-2000`	uso inválido	motor	2	uso inválido A linha de comando não se lê: um subcomando desconhecido, um argumento em falta ou uma flag que este comando não aceita. Corre o comando com --help e segue a linha de uso.
`DX-2601`	uso inválido	stack	2	o plano tem alterações O `stack plan --detailed-exitcode` encontrou diferenças entre o manifesto e o que está a correr. Não é uma falha. Revê o plano e corre `delonix stack apply` se as alterações forem desejadas.
`DX-3000`	não está a correr	motor	3	não está a correr O recurso existe mas não está a correr, e a operação precisa dele a correr. Arranca-o (`delonix container start <nome>`, `delonix vm start <nome>`) e tenta outra vez.
`DX-3101`	não está a correr	container	3	o container não está a correr O container existe, mas a operação precisa dele a correr. Arranca-o primeiro (`delonix container start <nome>`).
`DX-4000`	não existe	motor	4	esse recurso não existe Não existe nada com esse nome ou id neste âmbito. Confirma o nome e o namespace com o `ls` correspondente, ou cria primeiro o recurso.
`DX-4001`	não existe	motor	4	não há essa rota na API de nó O pedido chegou ao socket da API de nó com um método e um caminho para os quais ela não tem handler. O OpenAPI publicado (`GET /openapi.json`) lista o contrato; um caminho que lá esteja pode ainda não ser servido por esta versão do motor (DX-6001). Confere o método e o caminho no `GET /openapi.json`, ou abre o `GET /docs`.
`DX-4101`	não existe	container	4	esse container não existe Nenhum container responde a esse id, prefixo de id ou nome neste state root. Lista-os com `delonix container ps -a`.
`DX-4102`	não existe	container	4	dispositivo CDI não encontrado O nome do dispositivo não é declarado por nenhum spec CDI descoberto. Confere o nome do dispositivo contra o spec (`nvidia-ctk cdi list`), ou regenera-o.
`DX-4201`	não existe	volume	4	esse volume não existe Não existe nenhum volume com esse nome neste âmbito. Lista-os com `delonix volume ls` (-A para todos os namespaces), ou cria-o com `delonix volume create`.
`DX-4202`	não existe	volume	4	esse snapshot não existe O volume não tem nenhum snapshot com esse nome. Lista os snapshots dele com `delonix volume snapshot ls <volume>`.
`DX-4203`	não existe	volume	4	esse pool de armazenamento não existe Não há nenhum `kind: StoragePool` com esse nome em uso neste nó. A allowlist do administrador diz que pools podem ser usados; um pool passa a ser usado quando um `kind: StoragePool` o nomeia. Lista-os com `delonix get storagepools`, e aplica um `kind: StoragePool` com esse nome.
`DX-4301`	não existe	rede	4	não existe esse NetworkRoute Não existe nenhum NetworkRoute entre o par de redes dado. Lista as rotas com `delonix network route ls`, ou cria uma com `delonix network route <from> <to>`.
`DX-4302`	não existe	rede	4	não existe esse Service Não existe nenhum Service com esse nome nesse namespace. Lista os services com `delonix get services`.
`DX-4303`	não existe	rede	4	a rede de ingress não existe A rede nomeada não tem NetDef neste holder — nunca foi realizada aqui, ou foi removida. Cria-a com `delonix network create <name>`, ou usa a rede default.
`DX-4304`	não existe	rede	4	não existe essa rota da API do OPNsense A appliance respondeu HTTP 404 `{"errorMessage":"Endpoint not found"}` — o caminho módulo/controller/comando não existe nesta versão do OPNsense. Confere o caminho contra `docs.opnsense.org/development/api.html` para a versão exacta da appliance.
`DX-4401`	não existe	imagem	4	essa imagem não existe A imagem não está no store local e o registo não tem essa tag. Confirma a referência, ou descarrega-a primeiro (`delonix image pull`).
`DX-4402`	não existe	imagem	4	imagem ou repositório não visível O registo não mostra o repositório ou a imagem a estas credenciais: não existe, ou é privado. Faz login com credenciais que o possam ver (`delonix image login <registo>`).
`DX-4501`	não existe	vm	4	essa VM não existe Não existe nenhuma máquina virtual com esse nome neste state root. Lista-as com `delonix vm ls`, ou cria-a com `delonix vm create`.
`DX-4502`	não existe	vm	4	esse snapshot não existe A VM não tem nenhum snapshot com esse nome. Lista os seus snapshots com `delonix vm snapshot ls <vm>`.
`DX-4503`	não existe	vm	4	esse snapshot não existe A VM não tem instantâneo nenhum com esse nome no nó Proxmox. Lista os seus snapshots com `delonix vm snapshot ls <vm>`.
`DX-4504`	não existe	vm	4	não existe esse recurso no nó Proxmox O nó respondeu HTTP 404, ou disse que o ficheiro de configuração da VM não existe (o que diz com HTTP 500). Confere o id da VM no registo com o `qm list` do nó; uma VM removida do lado do nó deixa um registo sem nada por trás.
`DX-4505`	não existe	vm	4	essa rede não existe para a VM A VM nomeia uma rede que não está declarada neste nó. A criação parou antes de construir fosse o que fosse. Cria-a primeiro com `delonix network create <nome>` (ou um `kind: Network`), ou omite o `--network` para usar a rede por omissão.
`DX-4601`	não existe	stack	4	fonte GitOps inexistente Não há nenhuma `kind: GitOpsSource` com esse nome nesse namespace neste nó. Lista-as com `delonix get gitopssources`; uma fonte regista-se com `delonix stack apply`.
`DX-4801`	não existe	segurança	4	esse segredo não existe Não existe nenhum segredo com esse nome. Lista-os com `delonix secret ls`, ou cria-o com `delonix secret create`.
`DX-5000`	conflito	motor	5	conflito: já existe O nome já está tomado, ou o estado pedido entra em conflito com o que lá está. Escolhe outro nome, remove o recurso existente, ou usa o --force/--replace do comando, se o tiver.
`DX-5001`	conflito	motor	5	request_id reutilizado para um pedido diferente O registo de operações da API do nó responde a uma mutação repetida com o primeiro resultado gravado (ADR-0042 D2 "Idempotência"), identificado por request_id, verbo e alvo. Este request_id já produziu uma operação para o mesmo verbo e alvo, mas o pedido gravado não corresponde ao conteúdo deste (imagem, tamanho, namespace ou campos semelhantes diferem) — um request_id nomeia um pedido exacto, não um recurso. Gera um request_id novo (uma chave de idempotência deve ser única por pedido distinto, por exemplo um UUID novo por chamada), e envia os dois pedidos com as suas próprias chaves.
`DX-5002`	conflito	motor	5	a operação não pode ser cancelada A operação já terminou, ou está a correr para lá do ponto sem retorno: cada mutação que este motor serve na API de nó corre até ao fim depois de aceite, por isso nada foi cancelado e o estado da operação não mudou. Acompanha a operação até ao fim (`WatchOperation`, ou `GET /v1/operations/{id}`) e depois desfaz o que ela fez com o pedido inverso, se era isso que querias.
`DX-5101`	conflito	container	5	container já a correr O container está a correr, e a operação removê-lo-ia ou substituí-lo-ia sem --force. Pára-o primeiro, ou passa --force.
`DX-5201`	conflito	volume	5	o pool de armazenamento tem algo no caminho O pool ainda tem volumes deste motor, ou o objecto que foi pedido a um driver para criar ou libertar existe no pool sem a marca deste motor para este state root. Um objecto nunca é adoptado nem apagado pelo nome (ADR-0067 D5). Remove primeiro os volumes que a mensagem lista; para um objecto que não é deste motor, escolhe outro nome de volume ou pede ao dono que o remova.
`DX-5202`	conflito	volume	5	o pool de armazenamento não pode receber este volume A soma dos tamanhos alocados no pool passaria o seu tecto de sobre-alocação (`overcommit.maxRatio` vezes a capacidade), ou o pool já está acima de 95% de ocupação (ADR-0067 D6). Liberta espaço no pool, pede um volume mais pequeno, ou sobe o `overcommit.maxRatio` no `kind: StoragePool` sabendo que um pool cheio faz falhar todos os volumes que lá estão.
`DX-5203`	conflito	volume	5	o volume está em uso Um container monta o volume, ou uma partilha foi recortada dos seus dados, e removê-lo tirava-lhes os dados debaixo dos pés. Remove primeiro o que a mensagem lista (`delonix container rm`, `delonix volume rm <partilha>`), ou pede a remoção com force para destruir os dados na mesma.
`DX-5204`	conflito	volume	5	o pool de armazenamento não foi criado por este helper O `destroy-pool` só destrói um pool que a allowlist do administrador marca com um bloco `create:` e que traz a marca de criação do próprio helper. Um pool que já existia antes do motor, ou um sem a marca, nunca é destruído (ADR-0067 D5). Tira a entrada do pool de `/etc/delonix/storage-pools.yaml` para deixar de o usar; destruir o que o suporta é decisão do próprio administrador, fora deste motor.
`DX-5205`	conflito	volume	5	um dispositivo indicado para o pool não pode ser usado O `create-pool` foi recusado antes de escrever o que fosse: um dispositivo em `create.devices` do pool traz uma assinatura de sistema de ficheiros ou de volume, não resolve para um dispositivo de bloco, ou o volume group, zpool ou ponto de montagem que criaria já existe. Verifica o dispositivo que a mensagem nomeia. Para escrever por cima de uma assinatura, passa `--wipe-devices` no terminal, sabendo que isso destrói o que está no dispositivo.
`DX-5301`	conflito	rede	5	a rede já existe Já existe uma rede do NetworkStore com esse nome. Escolhe outro nome, ou remove primeiro a existente (`delonix network rm <name>`).
`DX-5302`	conflito	rede	5	não sobra subnet livre O espaço de endereços de workload não tem nenhum /16 livre para dar a uma rede nova. Remove uma rede não usada (`delonix network rm <name>`) para libertar um /16.
`DX-5303`	conflito	rede	5	a subnet sobrepõe-se a uma rede existente O CIDR pedido sobrepõe-se à subnet de uma rede existente. Escolhe um CIDR que não se sobreponha a nenhuma rede que o `delonix network ls` já mostra.
`DX-5304`	conflito	rede	5	a subnet da rede não pode ser mudada no lugar Já existe uma rede com este nome com uma subnet diferente da pedida; podem já existir workloads endereçados nela. Remove a rede (`delonix network rm <name>`) e cria-a de novo com a nova subnet.
`DX-5305`	conflito	rede	5	octeto base já usado por outra rede O /16 dado a uma chamada de create_with_base já está a ser usado por outra rede. Escolhe um octeto base diferente, ou remove a rede que já o tem.
`DX-5306`	conflito	rede	5	a rede de ingress já está realizada noutro prefixo Um NetDef de ingress já está realizado num prefixo diferente do que o registo agora pede. Remove a rede (`delonix network rm <name>`) e cria-a de novo, ou mantém a subnet registada.
`DX-5307`	conflito	rede	5	a rede está em uso A rede ainda tem containers, membros de pod ou VMs ligados, e removê-la deixá-los-ia endereçados numa bridge que já não existe. Remove ou desliga o que a mensagem lista (`delonix container rm`, `delonix network disconnect`, `delonix vm rm`) e só depois remove a rede.
`DX-5308`	conflito	rede	5	endereço já ocupado O endereço pedido já está arrendado a outro container, ou pertence ao pool que o servidor DHCP da rede entrega às VMs. Escolhe outro endereço (`delonix network ipam ls` mostra os arrendados), ou deixa o endereço ao motor.
`DX-5360`	conflito	rede	5	o conjunto de VIP sobrepõe-se a um intervalo em uso O conjunto de VIP partilha endereços com algo que este nó encaminha ou serve: uma rede do motor, um intervalo de pods CNI, a sub-rede de pods ou de serviços de um cluster kind, um endereço ou rota do host (uma VPN incluída), ou as sub-redes do próprio holder (ADR-0066 D2). Um VIP aí esconderia endereços reais. Escolhe um conjunto que nada neste nó use (`delonix network vip-pool set <cidr>`); a mensagem nomeia a origem sobreposta.
`DX-5389`	conflito	rede	5	o provider de rede tem algo que este motor não sobrescreve O provider remoto (um appliance OPNsense, o SDN de um cluster Proxmox) tem um objecto com a identidade que se quer garantir ou remover e sem a marca de dono deste motor (é de outra pessoa: nunca é adoptado pelo nome, nunca é apagado); ou um objecto que este motor criou foi editado lá e já não bate com o manifesto (não há actualização no lugar); ou tem alterações preparadas que não são deste motor, e o commit dele aplica tudo o que está preparado de uma vez. Reason `provider_conflict` da D5 do ADR-0059. A marca de dono é uma categoria de firewall chamada `delonix-owner:<token>` (OPNsense) ou `[delonix-owner:<token>]` no fim do alias de uma vnet (Proxmox). Lê qual dos três a mensagem nomeia: muda o nome do objecto ou remove o antigo no provider; repõe o objecto editado como foi declarado, ou substitui-o (`delonix stack apply --replace <Kind>/<nome>`); ou pede a quem preparou as outras alterações que as aplique ou descarte. Depois aplica outra vez.
`DX-5390`	conflito	rede	5	o plano foi calculado contra um estado que entretanto mudou O `stack apply --plan-digest` recebeu um digest, e o digest recalculado agora para um documento de rede não está entre os fornecidos: o manifesto, o que o provider tem, o provider, as suas capacidades ou o catálogo mudaram entre o plano e o apply. Razão `stale_plan` do ADR-0059 D5. Nada foi escrito. Volta a planear (`delonix stack plan -o json`), lê o que mudou e aplica com o `planDigest` novo.
`DX-5501`	conflito	vm	5	nome de VM já usado por outro subsistema de VM Já existe um registo de VM com este nome, criado pelo outro subsistema de VM (QEMU directo) que partilha a mesma pasta vms/. Remove-o primeiro (`delonix vm rm <nome>`), ou escolhe outro nome.
`DX-5502`	conflito	vm	5	nome de snapshot de VM já usado A VM já tem um snapshot com esse nome. Escolhe outro nome, ou remove o snapshot existente (`delonix vm snapshot rm`).
`DX-5503`	conflito	vm	5	nome de instantâneo já usado A VM já tem um instantâneo com esse nome no nó Proxmox. Escolhe outro nome, ou remove primeiro o instantâneo existente.
`DX-5504`	conflito	vm	5	o nó Proxmox reporta um conflito O nó respondeu HTTP 409, ou disse que o recurso já existe (o que diz com HTTP 500). Escolhe outro nome ou id, ou remove o que já lá está.
`DX-5505`	conflito	vm	5	a VM tem de estar parada para ser redimensionada O `vm resize` é um redimensionamento a frio: muda a definição com que a VM arranca. Um convidado a correr ou em pausa só veria a mudança no reinício seguinte, por isso o verbo recusa em vez de reportar um redimensionamento que não aconteceu. Corre `delonix vm stop <nome>`, redimensiona, e depois `delonix vm start <nome>`.
`DX-5506`	conflito	vm	5	a VM tem de estar parada para mudar o cloud-init O convidado lê o cloud-init no arranque: uma VM a correr ou em pausa ficaria com o hostname e as chaves antigas até ao reinício seguinte, por isso o verbo recusa em vez de reportar uma mudança que não chegou ao convidado. Corre `delonix vm stop <nome>`, muda, e depois `delonix vm start <nome>`.
`DX-5507`	conflito	vm	5	a VM não pode ser movida como foi pedido O `vm move` foi recusado antes de começar: a VM está no estado de energia errado para o que foi pedido (o `--live` precisa dela a correr, sem `--live` precisa dela parada), ou a pré-verificação do próprio nó diz que o destino não a pode receber — discos locais que o destino teria de copiar, um storage que o destino não tem, ou um dispositivo local. Pára ou arranca a VM de acordo com o `--live`; numa recusa da pré-verificação, põe os discos da VM num storage partilhado por todo o cluster, ou retira o dispositivo local.
`DX-5508`	conflito	vm	5	a rede do hipervisor não está na sub-rede declarada O hipervisor já tem uma rede com o nome que a VM pediu, numa sub-rede diferente da que foi declarada para ela. O motor só redefine uma rede assim quando foi ele que a definiu e nenhuma VM está nela; caso contrário recusa, porque ligar a VM colocá-la-ia numa sub-rede que ninguém declarou. Remove primeiro as VMs que ainda estão na rede antiga, ou dá outro nome à rede do delonix. Uma rede que o motor não definiu é do operador: altera-a ou remove-a com `virsh net-edit`/`virsh net-undefine`, se é isso que queres.
`DX-5515`	conflito	vm	5	a configuração SDN do cluster está trancada O Proxmox VE tem um único lock global sobre a configuração SDN (`POST /cluster/sdn/lock`). Enquanto outro detentor o tiver, todas as escritas SDN encenadas e o apply são recusados; o nó diz o mesmo quando o token que este cliente levava já não é o do lock. Espera que o detentor aplique ou reverta; se o detentor já não existir, liberta o lock com o token dele (`DELETE /cluster/sdn/lock`), ou com `force=1` quando tiveres a certeza de que ninguém o está a usar.
`DX-5516`	conflito	vm	5	o cluster tem alterações SDN pendentes O lock SDN foi recusado porque o cluster já tem alterações SDN encenadas que ninguém aplicou. Tomar o lock na mesma e aplicar empurraria esse outro trabalho junto com esta alteração. Descobre quem as encenou (a lista de alterações pendentes do `delonix`, ou o painel SDN do nó) e pede que sejam aplicadas ou revertidas primeiro.
`DX-5517`	conflito	vm	5	o container de sistema não pode ser movido como pedido O `systemcontainer move` foi recusado antes de qualquer coisa se mover: o container está a correr e não foi dado `--restart` (o nó não move um container a correr a quente), os seus volumes estão num storage que o destino não partilha e não foi dado `--with-local-disks` (o nó copiá-los-ia por inteiro), ou a verificação prévia do próprio nó não lista o destino. Passa `--restart` para o parar, mover e arrancar no destino, ou `--with-local-disks` para deixar o nó copiar os volumes, ou escolhe um nó que a verificação prévia permita.
`DX-5601`	conflito	stack	5	um recurso que o manifesto declara pertence a outrem — nada foi alterado O plano tem um `Conflict`: um recurso com este nome já tem o carimbo `delonix.io/stack` de outra stack, ou (uma VM) o provider tem uma que o registo deste nó não conhece. Duas stacks a convergir o mesmo recurso fá-lo-iam oscilar entre duas formas a cada apply, por isso o `stack apply` recusa o apply inteiro antes de se tocar em qualquer coisa, o `stack apply --dry-run` sai com este código depois de imprimir o manifesto, e o `stack plan --detailed-exitcode` sai com ele em vez de 0 ou 2. Nenhuma flag o autoriza. Aplica-o a partir da stack que é dona dele, remove-o lá primeiro, ou muda-lhe o nome neste manifesto; o `stack plan` diz quem é o dono.
`DX-6000`	indisponível	motor	69	indisponível neste host Falta uma ferramenta, um backend ou uma funcionalidade do kernel de que a operação precisa. Os argumentos estão certos. Instala o que a mensagem nomeia (o `delonix system info` mostra o que este host tem) e corre o comando outra vez.
`DX-6001`	indisponível	motor	69	a API de nó ainda não serve isto A operação está no contrato (`proto/delonix/node/v1`) e esta versão do motor não a serve: a mensagem nomeia o passo do ADR que a traz. O estado HTTP é 501 Not Implemented, não 503: repetir não ajuda. Entretanto usa a CLI para a operação, ou uma versão do motor que a sirva (o `GET /v1/node` dá a versão).
`DX-6101`	indisponível	container	69	o container ainda não acabou de montar O processo do container corre, mas o arranque passou o tecto da montagem antes de o init dizer que o sistema de ficheiros estava no sítio, por isso um comando que entre agora pode correr no sistema de ficheiros do host. Os comandos que entram nele são recusados até o init o dizer. Espera e tenta outra vez: a recusa levanta-se sozinha quando as montagens acabam. Se nunca acabarem, olha para os volumes que monta (um servidor NFS que não responde é a causa habitual) e reinicia o container.
`DX-6102`	indisponível	container	69	não foi possível criar ou limitar o grupo de cgroup do container Como root, um container que nomeia um grupo de cgroup fica sob `delonix.slice/<group>/`, e o tecto agregado do grupo é escrito antes de o container entrar. Criar o grupo, escrever um dos seus tectos, ou passar-lhe um controlador falhou — e um grupo sem o seu tecto não seguraria nada, por isso o container não é arrancado. Lê a mensagem para o ficheiro e o erro. Confirma que o `delonix.slice` passa aos filhos os controladores `memory`, `cpu` e `pids` (`delonix system doctor`), e que nenhum outro processo está directamente no directório do grupo.
`DX-6201`	indisponível	volume	69	não foi possível construir o cliente HTTP do TrueNAS A pilha TLS/HTTP local não conseguiu construir um cliente para o pedido. Não há nada de errado no manifesto. Verifica as bibliotecas TLS do host; `delonix system info` reporta o que este host tem.
`DX-6202`	indisponível	volume	69	versão do TrueNAS não suportada Esta build só fala uma versão maior da API REST do TrueNAS; a superfície muda entre versões maiores. Aponta o manifesto a uma appliance TrueNAS SCALE na versão maior suportada, ou actualiza este motor.
`DX-6203`	indisponível	volume	69	o pool de armazenamento não pode ser usado neste host Não existe allowlist de pools de armazenamento neste nó, o driver do pool não está construído nesta versão, ou a sonda encontrou o objecto de suporte em falta ou sem escrita. Nada foi criado. Segue o remédio da mensagem: pede ao administrador que declare o pool em `/etc/delonix/storage-pools.yaml`, cria o directório dele, ou dá a este utilizador acesso de escrita.
`DX-6204`	indisponível	volume	69	não foi possível determinar o estado do pool de armazenamento A listagem que diria se o pool é utilizável precisa de um privilégio que este processo não tem, ou a allowlist não pôde ser lida. Uma resposta vazia obtida sem o privilégio para listar nunca é lida como «não há pools» (ADR-0067 D3.5). Segue o remédio da mensagem; nada foi criado nem alterado.
`DX-6205`	indisponível	volume	69	este processo não consegue remover os dados do volume Parte dos dados do volume pertence a um subuid mapeado (escritos por um container num user namespace), e a API de nó ainda não tem forma de entrar nesse user namespace; remover o que consegue ler deixaria o volume meio apagado. Nada foi removido. Remove-o com `delonix volume rm <nome>`, que remove os dados mapeados de dentro do user namespace a que pertencem.
`DX-6206`	indisponível	volume	69	o helper privilegiado de armazenamento não está alcançável O driver do pool precisa de uma operação que só o root faz (LVM-thin, uma montagem ZFS), e neste nó não está configurado nem o helper activado por socket nem um motor root em `in-process`. Nada foi criado (ADR-0067 D3). Instala as units do helper e activa o `delonix-storage-helper.socket`, e acrescenta este utilizador ao `allowUsers` do pool; ou corre o motor como root com `mode: in-process` na allowlist.
`DX-6301`	indisponível	rede	69	o 'wg' não está disponível neste host As chaves de nó WireGuard e as redes overlay cifradas precisam do binário `wg`, que não está no PATH. Instala o wireguard-tools (Debian/Ubuntu: apt install wireguard-tools; Fedora/RHEL: dnf install wireguard-tools; Arch: pacman -S wireguard-tools).
`DX-6302`	indisponível	rede	69	esta rota da API de gestão já não altera a rede A rota escrevia no dataplane sem o registo do container, por isso o reapply seguinte desfazia-a e um workload com várias redes ficava com os outros endereços abertos. A API de gestão está congelada (ADR-0041 D4) e recusa em vez de escrever meia política. Usa a CLI, que passa pelo registo: `delonix net ingress`/`net egress` para firewall e saída, `delonix network connect`/`disconnect` para redes adicionais, `delonix container rm`/`stop` para desligar.
`DX-6305`	indisponível	rede	69	o isolamento por namespace não seria imposto neste host Foi pedida uma namespace com nome, mas o kernel não filtra o tráfego dentro de uma bridge (br_netfilter não carregado, ou net.bridge.bridge-nf-call-iptables=0). Todas as regras de isolamento seriam instaladas e nenhuma bloquearia nada. Carrega o br_netfilter e põe bridge-nf-call-iptables=1 (o `delonix system doctor` imprime os comandos, o `install.sh --tune` persiste-os), ou define DELONIX_ALLOW_UNENFORCED_ISOLATION=1 para correr sem isolamento de propósito.
`DX-6360`	indisponível	rede	69	nenhum conjunto de VIP configurado Foi aplicado um Service com `type: VirtualIP` num nó sem conjunto de VIP. Não há conjunto por omissão de propósito: uma reserva universal tiraria um intervalo a todos os hosts onde este motor corre (ADR-0066 D2). Configura um com `delonix network vip-pool set <cidr>` (ou `DELONIX_SERVICE_VIP_CIDR` para um processo), ou usa `type: DNS`.
`DX-6361`	indisponível	rede	69	o hairpin do VIP precisa de br_netfilter O tráfego em bridge não passa pelo netfilter no holder (`net.bridge.bridge-nf-call-iptables` não está a 1, ou o `br_netfilter` não está carregado), por isso um cliente na própria rede dos backends esgotaria o tempo no VIP (ADR-0066 D5). Carrega o módulo no host (`modprobe br_netfilter`); o `install.sh` fá-lo por omissão.
`DX-6381`	indisponível	rede	69	nenhum provider registado serve esta capacidade de rede O provider que serviria o pedido não está registado para o seu papel, ou não implementa a operação: um documento nomeia um que não está registado, o networkDefaults.<papel> nomeia um, ou o registo de um recurso nomeia o provider que o criou e esse provider já não está registado. Um default nunca é saltado para tentar outro provider, e um recurso registado nunca muda de provider (D3 do ADR-0059). Reason `unsupported_capability` da D5 do ADR-0059: o remédio é outro provider, não outro argumento. Configura o provider que a mensagem nomeia (`delonix provider ls` lista o que está registado), ou nomeia um que sirva o papel.
`DX-6383`	indisponível	rede	69	não foi possível chegar ao provider de rede O pedido ao provider de rede remoto (um appliance OPNsense) não pôde ser enviado ou não teve resposta: ligação recusada, DNS, TLS, ou uma ligação cortada a meio da resposta. Quando cortou depois de uma escrita ter sido enviada, não se sabe se a escrita chegou; o plano seguinte volta a ler o provider. Reason `provider_unavailable` da D5 do ADR-0059. Confirma que o url do provider no providers.yaml responde a partir deste host, e depois volta a planear e a aplicar.
`DX-6501`	indisponível	vm	69	backend de VM não configurado Este build conhece o backend nomeado, mas nada neste processo o configurou (por exemplo, Proxmox sem alvo definido). Configura-o como a mensagem descreve, ou usa um backend que já esteja disponível.
`DX-6502`	indisponível	vm	69	nenhum backend de VM disponível A auto-detecção não encontrou nem Cloud Hypervisor nem libvirt+qemu instalados. Instala cloud-hypervisor ou libvirt+qemu.
`DX-6503`	indisponível	vm	69	nenhum firmware de VM encontrado Arrancar uma cloud image no Cloud Hypervisor sem um kernel explícito precisa de um firmware, e nenhum foi dado nem encontrado embutido. Reinstala (curl install.sh) para obter o rust-hypervisor-fw, passa --firmware <caminho>, ou usa --backend libvirt.
`DX-6504`	indisponível	vm	69	cloud-localds não encontrado Gerar um seed NoCloud de cloud-init precisa da ferramenta cloud-localds, que não está no PATH. Instala-a (Debian/Ubuntu: cloud-image-utils, Fedora/Rocky: cloud-utils), ou passa um seed já feito.
`DX-6505`	indisponível	vm	69	não foi possível construir o cliente HTTP do Proxmox A pilha TLS/HTTP local não conseguiu construir um cliente para o pedido. Não há nada de errado no manifesto. Verifica as bibliotecas TLS do host; `delonix system info` reporta o que este host tem.
`DX-6506`	indisponível	vm	69	nó Proxmox indisponível O nó respondeu HTTP 502/503/504: a API está de pé mas não consegue servir o pedido agora (pveproxy sem backend, nó a reiniciar). Tenta mais tarde; verifica os serviços do nó (`pveproxy`, `pvedaemon`) e o quórum do cluster.
`DX-6507`	indisponível	vm	69	capacidade não suportada pelo backend O backend em que esta VM correria não marca uma capacidade exigida como utilizável neste host — ou, com auto-detecção, nenhum backend disponível o faz. A mensagem lista cada entrada por satisfazer com o estado e a razão do próprio provider. É o FAILED_PRECONDITION do contrato de nó com a razão CapabilityNotSupported (ADR-0050 D6). Escolhe um backend que a tenha (`delonix provider ls`, `--backend`), corrige o que falta ao host quando o estado é `unavailable-on-host`, ou retira a exigência.
`DX-6508`	indisponível	vm	69	a firewall de datacenter do Proxmox está desligada Um `NetworkPolicy` com `scope: vm` pediu regras numa VM de um cluster Proxmox cuja firewall de datacenter está desligada. Com ela desligada, nenhuma regra de nenhuma VM filtra nada, e aplicar a política anunciaria uma protecção que não existe (ADR-0052). O motor nunca a liga: isso muda também o que os próprios nós do cluster aceitam. Liga a firewall ao nível de Datacenter no cluster (Datacenter › Firewall › Options, ou `pvesh set /cluster/firewall/options --enable 1`), depois de verificar as regras de gestão dos nós, e aplica outra vez.
`DX-6509`	indisponível	vm	69	não foi possível fazer o backup com o sistema de ficheiros do convidado congelado Um backup consistente congela os sistemas de ficheiros do convidado através do agente QEMU no instante em que o disco é copiado, para que o arquivo guarde um sistema de ficheiros coerente. O convidado não estava a correr, o agente não respondeu, ou o log do backup do próprio nó não mostrou o congelamento e o descongelamento — e um backup que não se consegue provar consistente não é reportado como tal. Instala e arranca o `qemu-guest-agent` no convidado e define `agent=1` na VM; para uma VM parada, um backup simples já é consistente.
`DX-6510`	indisponível	vm	69	o storage de importação do nó não aceita imagens Uma VM Proxmox criada a partir de uma imagem local é enviada para um storage do tipo dir do nó, em `import/`, e o nó só o aceita num storage cujos tipos de conteúdo incluam `import` (ADR-0057). O motor nunca muda os tipos de conteúdo de um storage: isso é administrar o nó. Liga-o no nó (`pvesm set <storage> --content <tipos actuais>,import`, ou Datacenter › Storage › Edit › Content), ou aponta o `DELONIX_PROXMOX_IMPORT_STORAGE` / `storage.import` do providers.yaml para um storage que o tenha.
`DX-6511`	indisponível	vm	69	o storage de importação do nó não tem espaço para a imagem A imagem seria enviada para o storage de importação do nó, e esse storage tem menos espaço livre do que a imagem. O envio é recusado antes de começar, porque a recusa do próprio nó só viria depois de os bytes terem sido enviados. Liberta espaço no storage, ou aponta o `DELONIX_PROXMOX_IMPORT_STORAGE` / `storage.import` do providers.yaml para um storage com espaço.
`DX-6512`	indisponível	vm	69	o apply do SDN terminou OK mas um nó não o realizou Um apply da configuração SDN do cluster (`PUT /cluster/sdn`) lança uma tarefa `reloadnetworkall`, e essa tarefa termina OK quando o reload do nó de entrada tem sucesso — mesmo que o reload de outro nó tenha falhado. O motor lê então o conteúdo das zonas em cada nó online, e pelo menos uma vnet não estava `available` lá. A mensagem nomeia cada nó, zona e vnet com a razão dada pelo próprio nó. Lê o log da tarefa 'reload network' desse nó (`pvesh get /nodes/<nó>/tasks --typefilter srvreload`), corrige o que ele nomeia — muitas vezes o pacote `dnsmasq` para uma zona com `dhcp=dnsmasq`, ou a linha `source /etc/network/interfaces.d/*` em `/etc/network/interfaces` — e aplica outra vez.
`DX-6513`	indisponível	vm	69	o storage do nó não aceita arquivos de container Um container de sistema num nó Proxmox é criado a partir de um arquivo OCI que o motor envia para um storage do nó como template de container, e o nó só o aceita num storage cujos tipos de conteúdo incluam `vztmpl` (ADR-0058). O motor nunca muda os tipos de conteúdo de um storage: isso é administrar o nó. Activa-o no nó (`pvesm set <storage> --content <tipos actuais>,vztmpl`, ou Datacenter › Storage › Edit › Content), ou usa um storage que o tenha.
`DX-6514`	indisponível	vm	69	o storage do nó não tem espaço para o arquivo de container O arquivo de container seria enviado para um storage do nó, e esse storage tem menos espaço livre do que o arquivo. O envio é recusado antes de começar, porque a recusa do próprio nó só viria depois de os bytes terem sido enviados. Liberta espaço no storage, ou usa um storage com espaço.
`DX-6515`	indisponível	vm	69	os tectos de CPU e memória da VM não podem ser aplicados Um VMM do Cloud Hypervisor arranca dentro da sua própria folha de cgroup, com o CPU e a memória da VM como tectos da folha, para que o processo que segura os vCPUs e a RAM do convidado seja o limitado. Nenhuma folha pode existir para ele neste host (rootless sem cgroup delegado, ou nenhum fornecedor de folhas neste processo), ou um tecto não pegou na folha. Nada foi criado. Corre o motor onde ele possa criar cgroups: como root, ou rootless num scope delegado (`systemd-run --user --scope -p Delegate=yes -- delonix vm create ...`). Para arrancar a VM sem tectos de propósito, define DELONIX_ALLOW_UNENFORCED_LIMITS=1.
`DX-6601`	indisponível	stack	69	o git não está instalado Uma passagem GitOps obtém com o `git(1)` do sistema (ADR-0021 decisão 2: um subprocesso, não uma biblioteca), e este nó não tem nenhum no `PATH`. Instala o pacote `git` (`apt install git`, `dnf install git`).
`DX-6602`	indisponível	stack	69	não foi possível obter a fonte O `git fetch` da ref da fonte falhou: o remoto está inalcançável, a ref não existe, a chave ou a chave de host fixada foi recusada, ou o git recusou os objectos (`fsckObjects`). Nada foi lido e a stack em execução fica intacta. Verifica o URL e a ref, que o nó alcança o remoto, e que a chave de deploy e as chaves de host fixadas nos segredos nomeados são as certas.
`DX-6603`	indisponível	stack	69	não foi possível instalar o temporizador GitOps Uma fonte com `sync.automated: true` instala um temporizador systemd, e o `systemctl` falta ou recusou (sem gestor de utilizador nesta sessão, num nó rootless). Corre-o onde o systemd gere o utilizador (`loginctl enable-linger`), ou põe `sync.automated: false` e corre `delonix gitops reconcile` a partir do teu próprio agendador.
`DX-6701`	indisponível	cluster	69	RETIRADO — a CNI por omissão de um cluster kubeadm multi-nó já não é recusada Já não é emitido (mantido para que `explain DX-6701` continue honesto perante saídas antigas). Um cluster kubeadm com mais de um nó e `cni: default` era aqui recusado, porque a CNI por omissão era uma bridge local ao nó que não encaminha nada entre nós. O motor agora RESOLVE `default` para Cilium nesse caminho (`net_profiles::resolved_profile`), a rede de pods entre nós por omissão em HA — um só nó continua com a bridge, e `mode: kind` continua com o kindnet. Ver ADR-0078 (emendada a 2026-10-27). Nada a fazer: `cluster kubeadm` com vários nós e `cni: default` levanta sozinho um cluster Cilium funcional. Para escolher outra rede de pods, passa `--cni cilium\|calico\|flannel` (com `--experimental-cni`) ou `--cni none` para aplicares a tua.
`DX-6702`	indisponível	cluster	69	dois ou mais nós do cluster resolveram para o mesmo endereço Todas as máquinas de um cluster kubeadm foram provisionadas, mas duas ou mais resolveram para o MESMO endereço, por isso o bootstrap abriria uma sessão SSH por nó e várias cairiam na mesma máquina enquanto as restantes nunca seriam configuradas. A causa habitual é uma imagem golden que traz uma identidade cozida lá dentro: o `/etc/machine-id` não está vazio na imagem, cada clone deriva dele o mesmo identificador de cliente DHCP do systemd (DUID-EN, número de empresa 43793), e um servidor DHCP indexa as concessões pelo identificador de cliente quando existe um — por isso N clones são tratados como UM só cliente e uma única concessão migra para o que pediu por último, deixando-os todos com o mesmo endereço. Recusado aqui, antes de se preparar qualquer host; sem esta verificação a execução falhava muito mais tarde e muito mais longe, como um `mv: cannot stat '/tmp/delonix-cri'` sem relação aparente, vindo de um passo de preparação a competir consigo mesmo sobre um só host. Confirma com `virsh net-dhcp-leases <network>`: uma só entrada para N clones a correr, todos a partilhar o mesmo `Client ID or DUID`, é este bug. O `delonix vm image build` esvazia o `/etc/machine-id` como último passo desde a v0.10.0 — uma imagem construída antes disso guarda um id real, por isso reconstrói a imagem (`delonix vm image build`) e cria o cluster outra vez. Para uma imagem que não foi construída aqui, esvazia o ficheiro em vez de o apagar (`truncate -s 0 /etc/machine-id`, zero bytes, para o systemd gerar um por cada arranque) e remove qualquer estado de concessão DHCP ou DUID persistido em `/var/lib/dhcp/` e `/var/lib/systemd/network/`.
`DX-6703`	indisponível	cluster	69	a rede dos pods de um cluster vivo não se muda no lugar O cluster já corre um perfil de rede dos pods e o manifesto pede agora outro. Não há migração suportada: os dois perfis são donos do mesmo CIDR de pods, do mesmo `/etc/cni/net.d` e do mesmo estado de iptables/eBPF em cada nó, e nada neste motor drena, re-endereça e re-liga cada pod. Aplicar o segundo por cima do primeiro deixaria dois donos da rede dos pods e um cluster cujo comportamento depende de qual agente escreveu uma regra por último. O cluster fica intocado e continua a correr o perfil que tinha. Cria um cluster novo com o perfil que queres e migra as cargas. Se o objectivo é reparar uma instalação do MESMO perfil, volta a correr o apply: esse caminho é idempotente.
`DX-6704`	indisponível	cluster	69	não se obteve o artefacto da rede dos pods, ou ele não bateu com o digest O artefacto de instalação fixado para o perfil escolhido (um manifesto, ou um tarball de chart Helm) não se conseguiu descarregar, ou o conteúdo dele não bateu com o SHA-256 que esta release fixa. Em modo offline significa que o artefacto não está mesmo na cache local. Em qualquer dos casos o bootstrap para ANTES de aplicar qualquer coisa: um artefacto cujos bytes mudaram não se instala pela força do URL. Online: confirma o alcance de rede do próprio host ao publicador e volta a correr. Offline: enche a cache antes com `delonix cluster network fetch --cni <perfil>` numa máquina com alcance, e copia o `<root>/net-profiles/` para aqui. Um digest que não bate num publicador alcançável quer dizer que o pin desta release e o artefacto publicado discordam — reporta-o em vez de contornar.
`DX-7000`	permissão negada	motor	77	permissão negada O sistema operativo recusou por uma permissão: um ficheiro, um directório ou uma capability. Corrige a permissão no caminho que a mensagem nomeia, ou corre a partir de uma sessão que a tenha, e repete.
`DX-7201`	permissão negada	volume	77	a allowlist do administrador não permite isto O pool não está na allowlist de pools de armazenamento do administrador, ou o volume pedido é maior do que o `maxVolumeBytes` do pool. Um manifesto só pode usar o que o administrador declarou (ADR-0067 D3). Pede ao administrador que acrescente o pool a `/etc/delonix/storage-pools.yaml` ou que suba o `maxVolumeBytes`; ou usa um pool que o `delonix get storagepools` liste.
`DX-7202`	permissão negada	volume	77	o helper de armazenamento não serve este utilizador neste pool O helper lê o uid de quem chama no próprio socket (`SO_PEERCRED`) e só serve um uid que o `allowUsers` do pool nomeie. Um `allowUsers` vazio não serve ninguém. Pede ao administrador para acrescentar este utilizador ao `allowUsers` do pool em `/etc/delonix/storage-pools.yaml`.
`DX-7203`	permissão negada	volume	77	um comando de administração de pools precisa de root O `delonix-storage-helper create-pool` e o `destroy-pool` escrevem em dispositivos crus, volume groups e pools: só correm como root, num terminal, nunca por ordem de um manifesto. Corre-o com `sudo` num terminal.
`DX-7385`	permissão negada	rede	77	o provider de rede recusou a credencial O provider de rede remoto recusou o que recebeu: o OPNsense responde 401 a uma chave/segredo que não aceita, 302 para a página de login quando não chegou credencial nenhuma, e 403 a uma chave sem o privilégio que a rota pede (fase 0 do ADR-0051). Reason `provider_auth_failed` da D5 do ADR-0059. Verifica os ficheiros de chave e segredo que o providers.yaml nomeia, e que o utilizador da API tem os privilégios de firewall no appliance.
`DX-7601`	permissão negada	stack	77	o commit não está assinado por uma chave de confiança A fonte pede commits assinados e o `git verify-commit` não aceitou o commit contra o `allowed_signers` SSH em `trustedKeysRef`: sem assinatura, assinado por outra chave, ou assinado com GPG (só se verificam assinaturas SSH). Nada foi lido dele. Assina o commit com uma chave listada no segredo das chaves de confiança, ou acrescenta-lhe no nó a chave de quem assina.
`DX-7801`	permissão negada	segurança	77	excepção à verificação de origem não concedida pela política do nó Um container pediu uma excepção à anti-spoof (`--allow-source` ou `--no-source-check`) que a política de runtime deste nó não concede. São permissões, não tectos: sem `allowedSourcePrefixes` / `allowSourceCheckOptOut` na política nada é concedido. A recusa fica no registo de eventos. Pede ao administrador do nó que o conceda na política de runtime (`kind: RuntimePolicy`), ou retira a flag. Um prefixo tem de caber dentro de um que a política conceda.
`DX-7802`	permissão negada	segurança	77	recusado pela política de runtime do nó O ponto de admissão do nó (`policy.json`, `kind: RuntimePolicy`) recusou o workload antes de se criar fosse o que fosse: um container, pod ou VM pediu algo que a política proíbe (privilegiado, rede do host, um registo fora da lista, passthrough de dispositivos, ou o que o `workloadSecurity: baseline` recusa). Todas as razões são nomeadas, e a recusa fica no registo de eventos. É uma recusa de permissão, por isso sai com 77, como as outras recusas da política. Retira do pedido o que a política proíbe, ou pede ao administrador do nó que mude a política de runtime (`kind: RuntimePolicy`). `delonix describe runtimepolicies` mostra o que está em vigor.
`DX-8000`	prazo esgotado	motor	124	prazo esgotado O prazo passou com o trabalho por acabar. Nada recusou; pode ainda estar a terminar. Espera e volta a perguntar, ou aumenta o --timeout. Não recries o recurso por cima de um que ainda está a subir.
`DX-8101`	prazo esgotado	container	124	container ainda a sair depois do SIGKILL O `rm -f` matou o container, mas o seu processo ainda não tinha acabado de sair quando o prazo passou — normalmente preso no kernel a despejar o sistema de ficheiros do container para um disco ocupado. O container continua listado, para nenhum processo vivo ficar sem registo. Corre o mesmo `rm -f` outra vez quando o disco do host acalmar; remove o container assim que o seu processo tiver saído.
`DX-8201`	prazo esgotado	volume	124	job do TrueNAS esgotou o tempo Um job assíncrono na appliance (permissões, trabalho no dataset) não chegou a um estado terminal antes do prazo. Pode ainda estar a terminar na appliance; verifica-o lá antes de repetir.
`DX-8501`	prazo esgotado	vm	124	task do Proxmox esgotou o tempo Uma task no nó (criar, arrancar, instantâneo, destruir) não chegou a um estado terminal antes do prazo. Pode ainda estar a terminar no nó; verifica o registo de tasks do nó antes de repetir.
`DX-8502`	prazo esgotado	vm	124	lock de configuração da VM Proxmox ficou ocupado O nó continuou a recusar porque o lock de configuração da VM estava tomado (normalmente o qmeventd a limpar depois de um stop), para lá da janela de repetição. Verifica o registo de tasks do nó para esta VM; algo ainda está a segurar o lock.
`DX-8503`	prazo esgotado	vm	124	a VM não ficou de pé antes do tempo de arranque O `--wait` deu à VM o `--boot-timeout` inteiro e nunca a viu responder: ainda sem endereço, ou com um endereço que nunca respondeu. A VM fica como está, a correr. Acompanha o arranque com `delonix vm console <name>`; sobe o `--boot-timeout` para um convidado lento, ou `delonix vm rm` se não arrancar.
`DX-8504`	prazo esgotado	vm	124	o hipervisor atribuiu o recurso, mas o convidado ainda não o usou o `vm update` acrescentou uma vCPU ou memória e o hipervisor confirmou-o, mas dentro do prazo de espera o convidado não o activou (CPU online, bloco de memória online) — ou o backend não tem canal nenhum para ver o convidado (ADR-0068 D4). O registo já guarda o valor atribuído pelo hipervisor: um restart não o perde. Dá mais tempo ao convidado e verifica outra vez com `delonix vm describe`; um convidado sem a política de activação (ADR-0068 D8) pode nunca a activar por si próprio.
`DX-8601`	prazo esgotado	stack	124	o git não terminou a tempo Uma invocação do git numa passagem GitOps passou o seu tecto (120 s) e foi parada, para que um remoto pendurado não segure o lock da fonte até ao próximo disparo. Verifica que o remoto responde; o próximo disparo tenta outra vez.
`DX-9000`	falha do sistema	motor	1	uma chamada de sistema falhou O kernel recusou uma operação (clone, mount, setns…). A mensagem traz a operação e o errno. Lê o errno na mensagem; o `delonix system info` verifica os requisitos do host (user namespaces, delegação de cgroup).
`DX-9001`	falha do sistema	motor	74	erro de I/O O sistema de ficheiros recusou num caminho de que o motor precisa: disco cheio, directório em falta, montagem avariada. Verifica o caminho na mensagem e o espaço livre do state root (`delonix system df`).
`DX-9002`	falha do sistema	motor	1	registo de estado inválido Um registo de estado em disco não pôde ser lido ou escrito como JSON: está corrompido ou é de uma versão incompatível. Inspecciona o registo que a mensagem nomeia; repõe-no a partir de um snapshot (`delonix system snapshot restore`) se estiver corrompido.
`DX-9003`	falha do sistema	motor	1	não foi possível obter o bloqueio do estado O bloqueio que serializa a leitura-modificação-escrita de um registo de estado não pôde ser aberto ou obtido, por isso a escrita foi recusada em vez de arriscar perder uma concorrente. Confirma que o state root é gravável por este utilizador e não está num sistema de ficheiros sem flock.
`DX-9004`	falha do sistema	motor	1	o kernel não deu entropia O kernel não forneceu bytes aleatórios, de que a cifra e os valores gerados precisam. Confirma que o getrandom(2) funciona neste host (um kernel muito antigo ou um perfil seccomp restritivo).
`DX-9005`	falha do sistema	motor	1	a API de nó falhou ao responder A API de nó não conseguiu calcular a resposta: uma sonda que corre entrou em pânico ou um valor que lê não pôde ser obtido. A mensagem diz o que falhou. Lê a mensagem; o log do servidor (`delonix serve node-api`) tem o detalhe. Reporta-o se se repetir.
`DX-9201`	falha do sistema	volume	1	uma ferramenta de armazenamento falhou Uma ferramenta do host de que o volume precisa (mount, mkfs.ext4, resize2fs, losetup…) falhou ou não existe. A mensagem traz o erro dela. Lê o erro da ferramenta na mensagem; montar volumes de rede e quotas rígidas exige CAP_SYS_ADMIN.
`DX-9202`	falha do sistema	volume	1	pedido ao TrueNAS falhou O pedido HTTP à appliance não pôde ser enviado nem respondido (rede, TLS, DNS). Verifica o url do alvo e que a appliance é alcançável a partir deste host.
`DX-9203`	falha do sistema	volume	1	TrueNAS respondeu com um erro HTTP A API REST da appliance devolveu um estado fora de 2xx; a mensagem leva o corpo do erro próprio. Lê o corpo na mensagem — o TrueNAS põe ali o detalhe accionável.
`DX-9204`	falha do sistema	volume	1	não foi possível ler a resposta do TrueNAS A resposta da appliance não era o JSON que este cliente esperava. Verifica que a appliance está na versão maior suportada; a mensagem leva o início do corpo.
`DX-9205`	falha do sistema	volume	1	job do TrueNAS falhou Um job assíncrono na appliance terminou FAILED ou ABORTED; a mensagem leva a razão própria. Lê a razão da appliance na mensagem.
`DX-9206`	falha do sistema	volume	1	job do TrueNAS desapareceu A appliance deixou de reportar um job antes de chegar a um estado terminal, por isso não se sabe se o trabalho aconteceu. Verifica o dataset/permissões directamente na appliance.
`DX-9207`	falha do sistema	volume	1	dataset do TrueNAS não tem mountpoint A appliance reporta o dataset sem mountpoint, por isso não pode ser partilhado nem montado. Verifica o dataset na appliance; pode ser preciso definir um mountpoint explicitamente.
`DX-9208`	falha do sistema	volume	1	o estado do TrueNAS discordou do seu próprio relato A appliance relatou uma acção como feita, mas uma releitura logo a seguir discorda (dataset ausente depois de criar, ou ainda presente depois de apagar). Verifica o dataset directamente na appliance; nada aqui foi revertido.
`DX-9301`	falha do sistema	rede	1	uma chamada de sistema de rede falhou Uma ferramenta do host a que este motor recorre para redes (ip, nft, wg, bridge, um plugin CNI, newuidmap/newgidmap, ou uma syscall crua) não pôde correr ou terminou mal. A mensagem nomeia a operação e leva o erro próprio da ferramenta. Lê a operação e o erro na mensagem; verifica que a ferramenta está instalada e que o estado de rede do host está são.
`DX-9302`	falha do sistema	rede	1	não foi possível construir o cliente da API do OPNsense A pilha HTTP/TLS local não pôde ser construída a partir do Target dado (o mais provável é um certificado CA malformado). Confere `ca_cert_pem`/`insecure_tls` no Target; nada na appliance foi alcançado.
`DX-9304`	falha do sistema	rede	1	o OPNsense respondeu com um estado inesperado Um estado HTTP não-2xx para o qual este cliente não tem classe dedicada. A mensagem traz o estado e o corpo. Lê o estado/corpo na mensagem; pode ser uma versão contra a qual este cliente nunca foi medido (ADR-0051).
`DX-9307`	falha do sistema	rede	1	resposta do OPNsense demasiado grande Um corpo acima do tamanho que este cliente lê para memória (16 MiB) — a appliance, ou o que quer que tenha respondido em seu nome, não é um dos corpos JSON pequenos que esta API normalmente devolve. Isto não devia acontecer contra um OPNsense real; confere que não é outra coisa a responder nesse endereço.
`DX-9308`	falha do sistema	rede	1	a resposta do OPNsense não fez parse O corpo da resposta da appliance não fez parse como o JSON que esta chamada esperava. Lê o corpo em bruto na mensagem; a API da appliance pode ter mudado de forma numa versão mais nova/antiga do que a que a Fase 0 do ADR-0051 mediu (26.1.2).
`DX-9401`	falha do sistema	imagem	1	erro do registo Um registo OCI respondeu com um erro, ou não foi possível alcançá-lo. Verifica a referência da imagem, o teu login (`delonix image login`) e o caminho de rede até ao registo.
`DX-9402`	falha do sistema	imagem	1	não foi possível ler a árvore de módulos A leitura do directório de módulos falhou: uma permissão, um caminho em falta ou um erro de I/O. Confirma que o caminho na mensagem é legível por este utilizador.
`DX-9403`	falha do sistema	imagem	1	digest do conteúdo divergente O que o registo serviu não corresponde ao digest fixado ou declarado. O conteúdo foi recusado. Não contornes isto: o registo, um mirror ou a rede podem estar a adulterar. Descarrega outra vez de uma fonte de confiança.
`DX-9404`	falha do sistema	imagem	1	a montagem do overlay falhou A montagem do rootfs overlay da imagem falhou. Lê o errno na mensagem; o overlay rootless exige um kernel com overlayfs sem privilégio (`delonix system info`).
`DX-9501`	falha do sistema	vm	1	ferramenta de VM falhou Uma ferramenta externa de que o ciclo de vida desta VM depende (virsh, qemu-img, o processo cloud-hypervisor) não pôde ser corrida ou saiu mal. Lê o próprio erro da ferramenta na mensagem.
`DX-9502`	falha do sistema	vm	1	a API do Cloud Hypervisor falhou O VMM Cloud Hypervisor da VM a correr não pôde ser alcançado pelo seu api-socket local, ou respondeu com um estado não-2xx. Confirma que a VM ainda está viva (`delonix vm status`); um vmm que tenha morrido precisa de `delonix vm start`.
`DX-9503`	falha do sistema	vm	1	disco da VM corrompido após o stop o qemu-img check encontrou o disco de uma VM Cloud Hypervisor parada corrompido (BUG-VM-001) — uma verificação pós-stop, não o próprio stop a falhar. Corre `qemu-img check -r all` no disco que a mensagem nomeia; considera --backend libvirt para VMs que precisem de snapshots de disco fiáveis.
`DX-9504`	falha do sistema	vm	1	o snapshot precisa de uma VM parada O backend Cloud Hypervisor não consegue fazer snapshot/restore/delete-snapshot ao disco de uma VM a correr: o vmm segura-o em exclusivo. Pára a VM primeiro (`delonix vm stop`), ou usa --backend libvirt para checkpoints a quente.
`DX-9505`	falha do sistema	vm	1	sem descrição do domínio libvirt em disco Uma VM parada não tem nenhum <nome>.xml registado, por isso não há nada para redefinir para um verbo snapshot/restore. Arranca a VM uma vez (`delonix vm start <nome>`); a descrição é escrita nessa altura e fica desde então.
`DX-9506`	falha do sistema	vm	1	admissão da VM recusada A verificação de protecção do host recusou arrancar uma VM cuja memória pedida não cabe no que o host tem disponível. Pára outras VMs/containers, reduz a memória, ou baixa DELONIX_VM_RESERVE_MIB (por tua conta e risco).
`DX-9507`	falha do sistema	vm	1	o backup de disco a quente falhou Um passo do pipeline de backup de disco a quente (listar discos, preparar o overlay, snapshot, copiar, pivot) falhou. Lê o próprio erro do passo na mensagem; a VM fica a correr de qualquer forma.
`DX-9508`	falha do sistema	vm	1	não foi possível correr o cloud-localds A ferramenta cloud-localds não pôde ser arrancada, por uma razão que não a de estar em falta. Lê o erro na mensagem; verifica as permissões e o espaço livre do host.
`DX-9509`	falha do sistema	vm	1	cloud-localds falhou A ferramenta cloud-localds correu e saiu com um estado diferente de zero ao construir o ISO de seed. Verifica que o user-data/meta-data/network-config de cloud-init que lhe foi dado está bem formado.
`DX-9510`	falha do sistema	vm	1	pedido ao Proxmox falhou O pedido HTTP ao nó não pôde ser enviado nem respondido (rede, TLS, DNS). Verifica o url do alvo e que o nó é alcançável a partir deste host.
`DX-9511`	falha do sistema	vm	1	Proxmox respondeu com um erro HTTP A API REST do nó devolveu um estado fora de 2xx; a mensagem leva o corpo do erro próprio. Lê o corpo na mensagem — o Proxmox põe ali o detalhe accionável.
`DX-9512`	falha do sistema	vm	1	a resposta do Proxmox tinha a forma errada A resposta do nó fez parse como JSON mas não levava o que uma chamada específica precisava (um id de VM, um id de task). Verifica que a versão do Proxmox VE do nó bate com o que esta build espera.
`DX-9513`	falha do sistema	vm	1	task do Proxmox falhou Uma task no nó (criar, arrancar, instantâneo, destruir) terminou com um veredicto diferente de OK; a mensagem leva a razão própria do nó. Lê a razão do nó na mensagem, ou verifica o seu registo de tasks.
`DX-9514`	falha do sistema	vm	1	não foi possível ler a resposta do Proxmox A resposta do nó não era o JSON que este cliente esperava. Verifica que a versão do Proxmox VE do nó bate com o que esta build espera; a mensagem leva o início do corpo.
`DX-9515`	falha do sistema	vm	1	o Proxmox recusou a credencial O nó respondeu HTTP 401: o token da API está errado ou revogado, ou o ticket não pôde ser renovado. Confere o id e o segredo do token (ou a conta), e que o token não expirou no nó.
`DX-9516`	falha do sistema	vm	1	o Proxmox negou a operação O nó respondeu HTTP 403: a credencial é válida mas não tem o privilégio que esta rota exige (a mensagem nomeia a rota). Dá ao token ou à conta, no nó, o papel que a rota exige — privilégio mínimo, um papel por uso.
`DX-9517`	falha do sistema	vm	1	a resposta do Proxmox excedeu o limite de tamanho A resposta do nó foi maior do que este cliente está disposto a ler para memória. Verifica o que o nó está a servir nessa rota; uma resposta deste tamanho não é uma que o motor espere.
`DX-9525`	falha do sistema	vm	1	descartar uma alteração SDN falhada também falhou Uma alteração dentro de uma transacção SDN falhou, e o rollback que devia descartar o que ela tinha encenado (`POST /cluster/sdn/rollback`) também falhou: ficam no cluster alterações pendentes, e possivelmente o lock SDN. A mensagem nomeia as duas falhas e o token do lock. Reverte à mão com o token que a mensagem nomeia (`POST /cluster/sdn/rollback` com `lock-token` e `release-lock=1`) e repete a alteração.
`DX-9901`	falha do sistema	máquina	1	uma chamada de sistema do motor de containers falhou Uma operação do kernel que esta crate executa para construir ou gerir um container (clone, mount, setns, uma escrita de cgroup ou /proc) falhou. A mensagem leva a operação e o errno. Lê o errno na mensagem; o `delonix system info` verifica os requisitos do host (user namespaces, delegação de cgroup).

Code	Class	Domain	Exit	Message, meaning, what to do
`DX-0000`	success	engine	0	success The command did what it was asked. Nothing.
`DX-1000`	invalid argument	engine	1	invalid argument An argument, a flag value or a manifest field is not acceptable. The message names which. Correct the argument the message names and run the command again.
`DX-1101`	invalid argument	container	1	ambiguous container name The name exists in more than one namespace, so it does not say which container. Qualify it as <namespace>/<name>.
`DX-1102`	invalid argument	container	1	invalid memory limit The --memory value, or a Kubernetes resources.limits.memory, is not a byte count this engine understands. Use bytes (67108864) or a suffix (64M, 64Mi, 1G, 1Gi).
`DX-1103`	invalid argument	container	1	invalid CPU limit The --cpus value, or a Kubernetes resources.limits.cpu, is not a number of cores this engine understands. Use a decimal number of cores (0.5, 2); millicores (500m) are a Kubernetes spelling this flag does not take.
`DX-1104`	invalid argument	container	1	invalid cgroup weight A weight value (--cpu-weight, --io-weight) is outside the cgroup v2 range. Pass a weight between 1 and 10000.
`DX-1105`	invalid argument	container	1	invalid CPU set The --cpuset value does not parse as a CPU list (e.g. 0-3,6). Pass a comma-separated list of CPU numbers or ranges.
`DX-1106`	invalid argument	container	1	invalid command argument A command or entrypoint argument contains a NUL byte, which cannot be passed to execve. Remove the embedded NUL byte from the argument the message names.
`DX-1107`	invalid argument	container	1	empty command The container has no command to run: neither the image's ENTRYPOINT/CMD nor an explicit command was given. Pass a command, or use an image with an ENTRYPOINT or CMD.
`DX-1108`	invalid argument	container	1	no processes in the container An operation needing at least one live process (renice) found none. Check the container is actually running (`delonix container ps`).
`DX-1109`	invalid argument	container	1	unsafe live-mount path A container update --volume-add/--volume-rm target is refused by the same path-safety check bind mounts use. Use a target path that stays inside the container's own root filesystem.
`DX-1110`	invalid argument	container	1	live-mount source does not exist The host path given to a live bind-mount (container update --volume-add) does not exist. Check the source path on the host exists before mounting it live.
`DX-1111`	invalid argument	container	1	container shares the host mount namespace A live mount/unmount was asked of a container with no private mount namespace to change. This container cannot take a live volume change; stop and recreate it if one is needed.
`DX-1112`	invalid argument	container	1	live mount failed The forked helper that performs a live bind-mount inside the running container's namespaces exited with a failure, or was interrupted. Read the message for the exit code; retry the volume-add, or restart the container.
`DX-1113`	invalid argument	container	1	live unmount failed The forked helper that performs a live unmount inside the running container's namespaces did not succeed. Retry the volume-rm, or restart the container.
`DX-1114`	invalid argument	container	1	invalid CDI device name A --device value naming a CDI-qualified device is not vendor.com/class=name. Use the vendor.com/class=name form (e.g. nvidia.com/gpu=0).
`DX-1115`	invalid argument	container	1	kubelet cgroup placement needs the root runtime Placing a container in the cgroup hierarchy a CRI RunPodSandbox names needs privileges rootless, or an already-namespaced process, does not have. Run the CRI server as root, or do not request a kube cgroup parent in rootless.
`DX-1116`	invalid argument	container	1	invalid cgroup group The container names a cgroup group (`cgroup_parent`) whose name is not one safe path segment ([a-z0-9._-], at most 64 bytes, not `.`/`..`, not starting with `-`), or whose aggregate memory, CPU or process ceiling does not parse. Nothing is placed: a name that could climb out of the engine's base, or a ceiling the kernel would not get, is refused instead of dropped. Use a group name made of [a-z0-9._-]; give memory as bytes or a suffix (1G, 512Mi), CPU as a decimal number of cores (0.5, 2) and processes as a whole number or `max`.
`DX-1201`	invalid argument	volume	1	invalid volume name A volume name may only use letters, digits, dot, dash and underscore, and cannot start with a dot. Pick a name made of [A-Za-z0-9._-] that does not start with a dot.
`DX-1202`	invalid argument	volume	1	network volume without a device An nfs, cifs or webdav volume was asked for without the share to mount. Pass the share: --opt server=<host> --opt share=<path>.
`DX-1203`	invalid argument	volume	1	network volume record without a device A network volume is registered but its record lost the device to mount. Recreate the volume with its server and share.
`DX-1204`	invalid argument	volume	1	invalid snapshot name A snapshot name may only use letters, digits, dot, dash and underscore, with no slash or double dot. Pick a name made of [A-Za-z0-9._-].
`DX-1205`	invalid argument	volume	1	hard quota on a volume with data A hard quota (loopback) can only be set on an empty volume: it would hide the data already there. Create the volume with --quota, or empty it first.
`DX-1206`	invalid argument	volume	1	quota below current usage The new quota is smaller than what the volume already holds. Free space in the volume first, or ask for a larger quota.
`DX-1207`	invalid argument	volume	1	volume in use Shrinking a quota needs the volume unmounted, and a container is using it. Stop the containers that mount it, then change the quota.
`DX-1208`	invalid argument	volume	1	ambiguous volume name The name is both a volume in the workload's namespace and a global volume. Rename one of the two.
`DX-1209`	invalid argument	volume	1	invalid volume spec A -v value is not source:/target[:options]. Write it as source:/target, optionally with :ro.
`DX-1210`	invalid argument	volume	1	unsupported bind option The third field of -v names an option this engine does not implement (SELinux :z/:Z, :U). Use :ro, :rw or a propagation option (:rprivate, :rslave, :rshared).
`DX-1211`	invalid argument	volume	1	mount target is not absolute The path inside the container must start with a slash. Write the target as an absolute path, like /data.
`DX-1212`	invalid argument	volume	1	quota below TrueNAS' minimum TrueNAS refuses a quota under 1 GiB on a dataset; asking for less does not get rounded up, it gets refused. Ask for at least 1 GiB, or drop the quota to leave the dataset unlimited.
`DX-1213`	invalid argument	volume	1	invalid TrueNAS url The provisioning target's url has no scheme, an unsupported scheme, or no host. Write it as https://<host>[:port], with no path.
`DX-1214`	invalid argument	volume	1	credential in the TrueNAS url The url carries a username or password (userinfo), which is a credential hidden in the manifest instead of a kind: Secret. Remove the userinfo and pass the credential as apiKeySecret or passwordSecret.
`DX-1215`	invalid argument	volume	1	credential over plain http Sending an API key or password to a plain http:// TrueNAS target would put it on the wire in the clear. Use https://, with insecureTLS: true if the appliance serves its own self-signed certificate.
`DX-1216`	invalid argument	volume	1	invalid TrueNAS dataset name A ZFS dataset name has to be <pool>/<name>, with no '..', no empty component and no leading '-'. Write the dataset as <pool>/<name>, e.g. tank/projects.
`DX-1217`	invalid argument	volume	1	the storage pool request cannot be served as written A `kind: StoragePool`, a `spec.pool` or a `--pool` carries something a pool request may not: a device, a path or a command (those are the administrator's, in the allowlist), a size that is missing or does not parse, or a pool beside another backing for the same volume (ADR-0067 D2). Name only the pool; give the volume a `size`; and keep `pool` apart from `nfs`/`cifs`/`webdav`/`share`/`provision`/`quota`.
`DX-1218`	invalid argument	volume	1	the storage pool allowlist cannot be used The administrator's allowlist of storage pools exists and is refused: it does not parse, names a field nobody defined, an entry lacks what its driver needs, or the file can be written by someone other than its owner (ADR-0067 D3). Fix the file the message names (`/etc/delonix/storage-pools.yaml` unless DELONIX_STORAGE_POOLS_FILE says otherwise) and keep it mode 0644, owned by root or by the user running the engine.
`DX-1219`	invalid argument	volume	1	storage pool driver registration refused A storage pool driver was registered with no id. A programming error in the process that registered it, not in what was asked. Report it: the composition root registers the drivers, and one of them has an empty id.
`DX-1220`	invalid argument	volume	1	usage could not be fully measured A directory inside the volume could not be read (commonly sub-uid data from a container), so the measured usage is a lower bound, not the real total — shrinking on an unverified number can truncate data. Run as a user that can read every file in the volume, or verify its real size another way before shrinking.
`DX-1221`	invalid argument	volume	1	the storage helper refused the request The privileged storage helper read a request it does not serve: it does not parse, names a field the protocol does not have, names an operation the socket does not take (pool creation and destruction are administrator commands, never socket requests), or carries a pool, volume, size or state root outside what the protocol accepts (ADR-0067 D3). Nothing was done. Use the engine's own commands (`delonix volume create --pool`) rather than writing to the helper's socket; an administrator creates or destroys a pool at a terminal with `delonix-storage-helper create-pool\|destroy-pool <name>`.
`DX-1301`	invalid argument	network	1	invalid WireGuard key A string given as a WireGuard key is not 44 characters of base64 ending in '='. Pass a key exactly as `wg genkey`/`wg pubkey` produced it.
`DX-1302`	invalid argument	network	1	invalid CNI configuration A CNI config/conflist file, or a plugin's input built from it, is not valid JSON or has the wrong shape. Check the `.conflist`/`.conf` file the message names; validate it with a JSON linter.
`DX-1303`	invalid argument	network	1	could not encode a CNI plugin's input Building the JSON a CNI plugin reads on stdin failed. Check the plugin entry in the conflist for a value JSON cannot represent.
`DX-1304`	invalid argument	network	1	invalid CNI plugin result A CNI plugin's own stdout did not parse as the result the CNI spec expects. Check the plugin binary the message names is the version this host's conflist expects.
`DX-1305`	invalid argument	network	1	CNI plugin not found A plugin named in the CNI chain (or its `ipam.type`) is not a binary in CNI_PATH. Install the plugin binary the message names into CNI_PATH (default /opt/cni/bin).
`DX-1306`	invalid argument	network	1	invalid netns sysctl key A sysctl key given to be set inside a netns is not a plain `net.` name. Use a dotted `net.` key, as `sysctl` itself would accept.
`DX-1307`	invalid argument	network	1	invalid publish spec A `-p`/`--publish` spec has a protocol other than tcp/udp, a non-numeric port, or a host address that is not an IPv4 literal. Write it as [hostIp:]hostPort:contPort[/tcp\|udp], e.g. 8080:80 or 0.0.0.0:8080:80/tcp.
`DX-1308`	invalid argument	network	1	invalid publish port range A `-p` port RANGE has a non-numeric bound, an out-of-order/out-of-range port, or mismatched host/container widths. Use hostStart-hostEnd:contStart-contEnd with both sides the same width, within 1-65535.
`DX-1309`	invalid argument	network	1	invalid network rate spec A `--net-bps`/`--net-burst` value does not parse, is zero, or is out of range. Use a number with an optional k/m/g/t suffix, e.g. 10mbit or 512k.
`DX-1310`	invalid argument	network	1	network record is corrupted A NetworkStore record on disk is missing a field its driver needs (parent, subnet, vni, or the base octet). Remove the network and recreate it (`delonix network rm`, then `delonix network create`).
`DX-1311`	invalid argument	network	1	reserved network name The name asked for is `bridge` (the implicit default network) or a reserved driver name (`host`/`none`). Pick a different name.
`DX-1312`	invalid argument	network	1	invalid network name A network name may only use letters, digits, dash and underscore. Pick a name made of [A-Za-z0-9_-].
`DX-1313`	invalid argument	network	1	unsupported bridge subnet A --subnet for the bridge driver is not a 10.<workload-range>.0.0/16 this engine's IPAM can realize. Pass a 10.<lo>-<hi>.0.0/16 in the workload range, or omit --subnet to let the engine pick a free one.
`DX-1314`	invalid argument	network	1	invalid subnet An arbitrary --subnet CIDR is not a private prefix (RFC 1918) of a usable length. Use a private range (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) with a prefix between /8 and /28.
`DX-1315`	invalid argument	network	1	invalid network gateway A declared gateway is outside the network's prefix, or is the network/broadcast address. Pick an address inside the network's prefix that is not the network or broadcast address.
`DX-1316`	invalid argument	network	1	invalid /16 base octet A /16 base octet for a bridge network is outside the workload address space. Pick a base octet inside the workload range this engine reports.
`DX-1317`	invalid argument	network	1	no record to annotate The implicit default `bridge` network has no record on disk, so there is nothing to label/annotate. Annotate a user network instead; the default network cannot carry labels.
`DX-1318`	invalid argument	network	1	invalid network metadata key or value A label/annotation key is empty or contains '=' or a newline, or its value contains a newline. Use a key/value with no '=' and no newline.
`DX-1319`	invalid argument	network	1	invalid VNI An overlay network's VNI does not parse, or is outside 1..16777215. Pass a VNI between 1 and 16777215.
`DX-1320`	invalid argument	network	1	not an overlay network An overlay-peer operation was asked of a network whose driver is not `overlay`. Target a network created with `--driver overlay`.
`DX-1321`	invalid argument	network	1	invalid overlay peer An overlay peer spec has no node_ip. Write the peer as <node_ip> or <node_ip>=<pubkey>=<wg_ip>.
`DX-1322`	invalid argument	network	1	unknown network driver A `create_lan` driver is neither `macvlan` nor `ipvlan`. Use --driver macvlan or --driver ipvlan.
`DX-1323`	invalid argument	network	1	parent NIC not found A macvlan/ipvlan network's parent NIC does not exist on this host. Pass a NIC that `ip link` on this host actually shows.
`DX-1324`	invalid argument	network	1	invalid macvlan/ipvlan subnet A macvlan/ipvlan subnet does not parse as a CIDR. Write it as e.g. 192.168.1.0/24.
`DX-1325`	invalid argument	network	1	invalid holder control command A line sent on the holder's control socket is not one this build recognises. Check the CLI and the holder are from the same build; an old holder may need a respawn.
`DX-1326`	invalid argument	network	1	invalid hex payload A hex-encoded payload on the holder control socket (a CNI conflist, a firewall spec) does not decode. This is an internal protocol error between the CLI and the holder; check they are the same build.
`DX-1327`	invalid argument	network	1	invalid FDB/overlay peer destination An FDB or overlay-peer destination is not a bare IP address. Pass a plain IPv4 address, with no other characters.
`DX-1328`	invalid argument	network	1	the default ingress bridge cannot be removed An attempt was made to remove the default ingress bridge, which every other network path depends on. Remove a user network instead; the default bridge is not removable.
`DX-1331`	invalid argument	network	1	invalid port A port string given to the ingress dataplane (publish/unpublish/lbset) is not 1..65535. Pass a numeric port between 1 and 65535.
`DX-1332`	invalid argument	network	1	invalid protocol A protocol other than tcp/udp was given to a publish/unpublish call. Use tcp or udp.
`DX-1333`	invalid argument	network	1	invalid egress policy An egress policy is not allow, deny, or allowlist:<cidrs>. Use allow, deny, or allowlist:<comma-separated CIDRs>.
`DX-1334`	invalid argument	network	1	invalid egress hostname An `egress host` suffix is not a plain DNS name. Use a plain hostname/domain suffix, e.g. example.com.
`DX-1335`	invalid argument	network	1	IP outside the ingress address space A container/publish IP is outside the ingress address space (10.200-254.x). Attach the container to a network inside the ingress range this engine reports.
`DX-1336`	invalid argument	network	1	firewall applied with no IP apply_firewall/apply_firewall_all was called with an empty IP list. This is an internal call error; report it if you see it from the CLI.
`DX-1337`	invalid argument	network	1	invalid firewall spec A firewall spec (hex-decoded JSON sent to the holder) does not parse as the expected structure. Check the CLI and the holder are from the same build.
`DX-1338`	invalid argument	network	1	could not encode a firewall spec Encoding a container's firewall to send over the control socket failed. This is an internal call error; report it if you see it from the CLI.
`DX-1339`	invalid argument	network	1	no free ingress prefix No /16 prefix is left in the ingress address space for a new network. Remove an unused network (`delonix network rm`) to free a prefix.
`DX-1340`	invalid argument	network	1	IP does not belong to network A fixed IP given to attach a container is not inside the target network's subnet. Pass an address inside the network's own subnet (`delonix network inspect <name>`).
`DX-1341`	invalid argument	network	1	invalid gateway provider registration A GatewayProvider registration (ADR-0051) had no id, or claimed a name another provider already has. Fix the registration the message describes; this is a programming error in the process that registered it, not a manifest/flag.
`DX-1344`	invalid argument	network	1	network zone provider registration refused A process tried to register a SegmentProvider with an empty id, or one whose id/alias already belongs to a different provider. Fix the registration (an internal call error unless a third-party provider crate is involved).
`DX-1349`	invalid argument	network	1	the OPNsense URL would send the API key in the clear The OPNsense target URL is not https://, names no host, or carries userinfo (`user:pass@`). The key/secret pair goes in every request's Authorization header, so plain HTTP hands it to anything on the path, and userinfo is a password in the configuration under another name. Use https://<host> (with `tls.insecureSkipVerify: true` or a `caFile` for the appliance's self-signed certificate) and keep the credential in `auth`.
`DX-1360`	invalid argument	network	1	invalid VIP pool A VIP pool (`network vip-pool set`, `DELONIX_SERVICE_VIP_CIDR`) is not a private IPv4 prefix (RFC 1918 or 100.64.0.0/10) between /16 and /29 written with its host bits clear, or two pools overlap (ADR-0066 D2). Give one or more non-overlapping private prefixes such as 10.90.0.0/16.
`DX-1361`	invalid argument	network	1	VIP outside the pool A Service's `spec.vip` is not inside any configured VIP pool, or is the pool's network, first or broadcast address. Pick an address inside the pool `delonix network vip-pool show` prints, or drop `spec.vip` and let the engine choose.
`DX-1380`	invalid argument	network	1	the network intent cannot be served as written What a network document or providers.yaml asks for cannot be served as written: nothing names a provider for the role and nothing else decides (zero or several registered, or a providers.yaml without networkDefaults.<role>), or the provider rejected the fields sent (OPNsense answers with per-field validations). ADR-0059 D5 reason `invalid_intent`. Read the message: name the provider (networkDefaults.<role> in providers.yaml, or spec.provider where the Kind has it), or fix the fields the provider listed.
`DX-1401`	invalid argument	image	1	empty SBOM The image has no apk or dpkg package database, so there is nothing to scan for vulnerabilities. Scan an image built on a distribution with a package manager, or scan its base image instead.
`DX-1402`	invalid argument	image	1	invalid advisory database The advisory database the scanner loaded is not valid JSON. Sync it again with `delonix image scan --update --feed <url>`.
`DX-1403`	invalid argument	image	1	OSV feed is not JSON The feed given to the scanner could not be parsed as JSON. Check the --feed URL points at an OSV JSON export, not an HTML page.
`DX-1404`	invalid argument	image	1	OSV feed has the wrong shape The feed is JSON but neither an array of advisories nor an object with a vulns array. Point --feed at an OSV export: an array of advisories, or an object with a vulns array.
`DX-1405`	invalid argument	image	1	not an Odoo module The directory named as a module has no __manifest__.py. Point the scan at the module's own directory, the one holding __manifest__.py.
`DX-1406`	invalid argument	image	1	no Odoo module found No directory under the path given has a __manifest__.py. Point the scan at the directory that contains the modules.
`DX-1407`	invalid argument	image	1	invalid Dockerfile The build file does not parse, or asks for an instruction or flag this engine does not support. The message names the line. Fix the line the message names; `delonix build --help` lists what is supported.
`DX-1408`	invalid argument	image	1	invalid image archive The archive being loaded is incomplete or corrupt: a missing manifest, or a blob that does not hash to its name. Export the archive again from its source and load the new file.
`DX-1409`	invalid argument	image	1	a layer could not be packed or unpacked Reading, compressing or extracting a layer or a root filesystem failed. The message carries the underlying error. Read the error in the message; check free space in the state root (`delonix system df`) and try again.
`DX-1410`	invalid argument	image	1	image has no layers The image record has no layers to mount as a root filesystem. Pull or build the image again.
`DX-1411`	invalid argument	image	1	the state root cannot back an overlay The state root path contains a character (':') that the overlay mount options cannot express. Move the state root to a path without ':' (DELONIX_ROOT).
`DX-1412`	invalid argument	image	1	invalid signing key A signing or verification key is not a valid P-256 key in PEM, or could not be generated. Pass a cosign-compatible ECDSA P-256 key in PEM.
`DX-1413`	invalid argument	image	1	image not signed The registry has no cosign signature for the image's digest. Sign it with `delonix image sign`, or pull a signed image.
`DX-1414`	invalid argument	image	1	invalid signature A signature exists but does not verify against the given key, or its manifest or payload is malformed. Check the key is the one the image was signed with; do not run an image whose signature fails.
`DX-1415`	invalid argument	image	1	signature state unknown The registry did not answer the signature lookup, so whether the image is signed could not be decided. This is not a verdict. Retry when the registry is reachable; the message carries the registry's error.
`DX-1416`	invalid argument	image	1	image already signed A signature for this digest already exists. Pass --force to sign it again.
`DX-1417`	invalid argument	image	1	could not sign Producing or uploading the signature failed. Read the error in the message and check the registry login (`delonix image login`).
`DX-1418`	invalid argument	image	1	layer expands beyond the unpack limit A layer holds more uncompressed bytes or more entries than the unpack limits allow, so it was refused while being streamed, before it could fill the disk. A small blob can expand to terabytes; the limits are what stops that. Use a smaller image. If the image is trusted and really that large, raise DELONIX_LAYER_MAX_BYTES or DELONIX_LAYER_MAX_ENTRIES.
`DX-1501`	invalid argument	vm	1	not supported on this backend The pause, unpause, snapshot, restore or delete-snapshot verb asked for is not implemented by this VM's backend. Use a backend that supports it (libvirt supports the most), or drop the verb.
`DX-1502`	invalid argument	vm	1	invalid VM backend registration A backend registration had no id, claimed auto-selection from outside this crate, or claimed a name another backend already has. Fix the registration the message describes; this is a programming error in the process that registered it, not a manifest/flag.
`DX-1503`	invalid argument	vm	1	unknown VM backend The --backend/DELONIX_VM_BACKEND value does not name a registered backend. Use one of the backends the message lists.
`DX-1504`	invalid argument	vm	1	VM record names an unregistered backend The VM's own record names a backend this process has no registration for. Run a build/process that registers that backend, or recreate the VM with one that is registered here.
`DX-1505`	invalid argument	vm	1	requires the libvirt backend The VM's spec.volumes need virtio-9p, which the Cloud Hypervisor backend does not implement. Remove `backend: cloud-hypervisor`, or drop the volumes.
`DX-1506`	invalid argument	vm	1	VM socket path too long The VM's api-socket or console socket path would not fit in a UNIX socket's sun_path (108 bytes on Linux). Use a shorter VM name or a shorter DELONIX_ROOT.
`DX-1507`	invalid argument	vm	1	invalid VM name A VM name may only use letters, digits, dot, dash and underscore, with no path traversal. Pick a name made of [A-Za-z0-9._-] with no '/', '..', or leading '-'.
`DX-1508`	invalid argument	vm	1	namespace not enforceable on this backend The VM's backend does not put its VMs on this engine's SDN, so namespace isolation cannot be enforced. Use `--backend cloud-hypervisor`, or drop `--namespace`.
`DX-1509`	invalid argument	vm	1	--disk-size smaller than the base image A qcow2 overlay cannot be smaller than its backing file. Ask for a --disk-size at least as large as the base image.
`DX-1510`	invalid argument	vm	1	invalid snapshot name A VM snapshot name may only use letters, digits, dot, dash and underscore, with no path traversal. Pick a name made of [A-Za-z0-9._-] with no '/', '..', or leading '-'.
`DX-1511`	invalid argument	vm	1	--ip requires the libvirt nat mode A static IP is materialized as a DHCP reservation on the libvirt network, which only the nat/network net mode has. Drop --net-mode, or set it to nat, to use --ip; on a host bridge, reserve the IP on the LAN's own DHCP instead.
`DX-1512`	invalid argument	vm	1	invalid static IP The --ip value does not parse as an IPv4 address. Pass a dotted-quad IPv4 address.
`DX-1513`	invalid argument	vm	1	could not reserve the static IP virsh net-update refused the DHCP host reservation for this MAC/IP pair. Read the virsh reason in the message; the IP may be outside the network's subnet.
`DX-1514`	invalid argument	vm	1	live disk backup needs the libvirt backend A live (running-VM) disk backup uses virsh blockcommit, which only the libvirt backend has. Stop the VM and take an offline snapshot instead, or recreate it on the libvirt backend.
`DX-1515`	invalid argument	vm	1	VM not in the right state for this verb pause needs a running VM and unpause needs a paused one; the VM is in neither state. Check `delonix vm status <name>` and use the verb that matches its current state.
`DX-1516`	invalid argument	vm	1	could not copy the cloud-init user-data The file a --user-data override names could not be copied into the VM's seed directory. Check the path exists and is readable by this user.
`DX-1517`	invalid argument	vm	1	no such Proxmox node The node named in the target is not part of the cluster this url answers for. Point the target at a node `GET /nodes` on this cluster actually reports, or fix the url.
`DX-1518`	invalid argument	vm	1	invalid Proxmox url The target url has no scheme, a scheme other than https, or no host. Write it as https://<host>:8006, with no path.
`DX-1519`	invalid argument	vm	1	credential in the Proxmox url The url carries a username or password (userinfo), which is a credential hidden in the manifest instead of a kind: Secret. Remove the userinfo and pass the credential as a Proxmox API token or password secret.
`DX-1520`	invalid argument	vm	1	invalid Proxmox bridge name A bridge name is interpolated into the VM's net0 property, and has to be a valid Linux interface name. Use a name like vmbr0: letters, digits, '-', '_' or '.', up to 15 characters.
`DX-1521`	invalid argument	vm	1	invalid Proxmox node name A node name goes into a URL path on every call, and has to be what Proxmox itself accepts. Use letters, digits, '-' and '.', matching the node's name in `pvecm status`.
`DX-1522`	invalid argument	vm	1	invalid Proxmox disk spec A VM's disk on this backend has to name a template to clone or a storage and size on the node; a local path has no meaning there. Write `template:<vmid>` to clone a template, or `<storage>:<size-in-GiB>` for a fresh disk, e.g. local-lvm:8.
`DX-1523`	invalid argument	vm	1	invalid Proxmox snapshot name A snapshot name goes into a URL path and into Proxmox's own namespace, and 'current' is reserved for the live state. Use letters, digits, '-' and '_', and not 'current'.
`DX-1524`	invalid argument	vm	1	unsupported field on the Proxmox backend The manifest asks for a local kernel/initrd/seed/device, a QEMU tuning knob the node owns, or a libvirt-only escape hatch — none of which this remote backend can honour. Remove the field the message names, or use a local backend (`--backend libvirt`).
`DX-1525`	invalid argument	vm	1	VM has no Proxmox handle The VM's record carries no Proxmox handle, so it was not created by this backend and this backend does not know its vmid. Manage this VM with the backend that created it.
`DX-1526`	invalid argument	vm	1	Proxmox rejected the request The node answered HTTP 400/422: a parameter of the request is not acceptable to it; the message carries the node's own reason. Read the node's reason in the message and correct the field it names.
`DX-1527`	invalid argument	vm	1	unknown capability A `required_capabilities` entry (`vm create --require`, `spec.requiredCapabilities`) names something the capability catalog does not have — a typo, or a name from another catalog version. It is refused before any backend is asked. Use a name from `delonix provider ls` (the catalog version is in its header).
`DX-1528`	invalid argument	vm	1	invalid Proxmox firewall rule A rule of the node's OWN firewall (not this engine's SDN firewall) named a `type` other than 'in'/'out', or an `action` other than ACCEPT/DROP/REJECT — a firewall group's name is a different kind of value this client does not validate and does not accept. Use 'in' or 'out' for the type, and ACCEPT, DROP or REJECT for the action.
`DX-1529`	invalid argument	vm	1	invalid Proxmox cloud-init dump type cloudinit_dump's `type` has to be one of the three the node's cloud-init route accepts, and is refused here before any request goes to the node. Ask for 'user', 'network' or 'meta'.
`DX-1530`	invalid argument	vm	1	invalid Proxmox SDN zone or vnet id A zone or vnet id goes into a URL path and into the node's own SDN namespace, which Proxmox limits to a lowercase letter followed by up to 7 more lowercase letters or digits (8 characters total). Pick an id of at most 8 characters, starting with a lowercase letter, the rest lowercase letters or digits.
`DX-1531`	invalid argument	vm	1	invalid Proxmox firewall alias or ipset name An alias or IP-set name of the VM's OWN firewall (not this engine's SDN firewall) goes into a URL path and into the node's own namespace, which Proxmox limits to a letter followed by one or more letters, digits, '-' or '_' (at least 2 characters total). Pick a name that starts with a letter and has at least one more letter, digit, '-' or '_' after it.
`DX-1532`	invalid argument	vm	1	invalid Proxmox firewall address A CIDR/address given to a firewall alias or to one entry of a named IP set is not an IPv4/IPv6 address, optionally with a '/<prefix>' — the node's own alias/ipset routes reject it before anything else would. Give an IPv4 or IPv6 address, or a CIDR range such as '10.0.0.0/8'.
`DX-1533`	invalid argument	vm	1	invalid Proxmox SDN subnet CIDR An SDN subnet is named by a CIDR network (an IPv4 or IPv6 address with a prefix length), refused here before it goes into a request body or, with its `/` swapped for `-`, into a URL path. Give a CIDR like '10.0.0.0/24' or 'fd00::/64', with a prefix length valid for the address family.
`DX-1534`	invalid argument	vm	1	invalid Proxmox SDN address A plain IPv4/IPv6 address (a DHCP range end, a DNS server, an IPAM reservation, a fabric node's router address) or a MAC address that an SDN field takes did not parse as one, refused before it goes into a request body or a URL. Give the address without a prefix length ('10.0.0.50', 'fd00::5'), or the MAC as XX:XX:XX:XX:XX:XX.
`DX-1535`	invalid argument	vm	1	invalid Proxmox shutdown timeout A guest-driven shutdown or reboot was asked to wait longer than this client waits for any node task, so the client would give up while the node was still inside the task. Give a timeout shorter than the client's task deadline (600 seconds by default), or omit it to take the node's own default.
`DX-1536`	invalid argument	vm	1	invalid VM resize `vm resize` needs `--vcpus` and/or `--memory`; vCPUs have to be at least 1 and memory a number with an optional M/G suffix (`512M`, `4G`, `4Gi`). A value that does not parse is refused rather than read as a default. Pass `--vcpus <n>` (n ≥ 1) and/or `--memory <size>`, e.g. `--memory 4G`.
`DX-1537`	invalid argument	vm	1	invalid cloud-init change `vm cloud-init` needs `--hostname`, `--user` and/or `--ssh-key`; the hostname has to be a DNS label (letters, digits, '-', at most 63), the user a login name, each key one line. An appliance image does not run cloud-init and is refused. Give at least one of the three, in the form the guest accepts — e.g. `--hostname web-1 --ssh-key @~/.ssh/id_ed25519.pub`.
`DX-1538`	invalid argument	vm	1	invalid node to move the VM to `vm move --node` names the node of the VM's cluster the VM goes to. The name has to be a member of that cluster, online, and not the node the VM is already on; the engine never picks one. Pass another member of the cluster that is online — the node's own list is `pvecm nodes`, or `delonix provider describe proxmox --probe`.
`DX-1539`	invalid argument	vm	1	the local image could not be read A Proxmox VM created from an image of the engine's store is uploaded to the node first (ADR-0057). The file the image resolved to could not be opened or read, or it is empty. Check the image with `delonix vm image ls` and `delonix vm image describe <name>`; pull or build it again if the file is missing.
`DX-1540`	invalid argument	vm	1	the system container asks for something the node cannot hold A system container on a Proxmox node is always unprivileged: a privileged one would be a privilege decision on a remote host, with its own spike (ADR-0058). Its entrypoint is stored as one line split on spaces, so an argument with a space or a control character cannot be kept as written; its environment is a list of NAME=value, where the name is letters, digits and underscores. Leave `unprivileged` true, write the entrypoint as arguments without spaces (or wrap it in a script inside the image), and name each variable with letters, digits and underscores only.
`DX-1550`	invalid argument	vm	1	invalid Proxmox SDN controller, prefix list or route map A BGP/EVPN controller, prefix list or route map of the cluster's own SDN (not this engine's) was refused before any request: an id outside Proxmox's own format (a controller id starts with a letter; a prefix-list or route-map id is 1 to 32 letters, digits, '-' or '_', and the node reserves some), a missing field the controller type needs (EVPN: an ASN and exactly one of peers/fabric; BGP: a node, an ASN and peers), or an entry field the node would not accept (action other than permit/deny, a prefix length past the address family, an unknown match/set key). Correct the field the message names; the node's own `apidoc.js` lists the formats.
`DX-1552`	invalid argument	vm	1	the Proxmox vnet firewall is not written by this engine A write to a Proxmox vnet's own firewall — its options, a new rule or a changed rule — is refused before any request, whatever its fields. Whether a vnet rule filters anything is decided per node by the host firewall's `nftables` option, under `/nodes/{node}/firewall`, which this engine does not read (ADR-0049 D3: host administration); under the default iptables firewall the node stores the rule and filters nothing. A write that could be reported as protection that does not exist is refused instead. Even where it is enforced, a vnet rule filters traffic bridged between guests of that one vnet, not traffic routed between vnets. For traffic to or from one guest, use its own firewall (`NetworkPolicy` with `scope: vm` or `scope: systemcontainer`). Writing a vnet's firewall needs an owner decision to read the node's firewall options first (an ADR-0049 addendum).
`DX-1601`	invalid argument	stack	1	invalid GitOps source A `kind: GitOpsSource` was refused before anything was fetched (ADR-0021): a URL that is not file:///, https:// or ssh:// (or carries credentials, or reads as an option), a ref that is not refs/heads/<n> or refs/tags/<n>, a path that leaves the repository, an interval outside 15s–24h, an ssh:// source without a key and pinned host keys, signed commits without trusted keys, a safety policy naming an action or Kind it cannot, or a referenced secret that does not exist on the node. Fix the field the message names. Credentials are named (`secretRef`, `knownHostsRef`, `trustedKeysRef`) and created on the node first, never carried in the URL or the repository.
`DX-1602`	invalid argument	stack	1	the commit was refused — nothing was applied A pass of a GitOps source read the commit and refused it before applying anything: the path is empty or missing, a symlink, a submodule, an LFS pointer or private key material is under it, the YAML does not load, a document is refused by the pull-source guard (a Kind a source never applies, host access, the source's own credential, another source, a namespace other than the source's), or the graph or the plan fails. The running stack is untouched. Read the lines the pass printed above the error, or `delonix gitops status`, fix the repository and push a new commit — the next pass picks it up.
`DX-1603`	invalid argument	stack	1	the source exceeds a bound a pass reads A pass refuses what it would not bound: more than 4096 entries under the path, more than 256 manifest files, a manifest file over 1 MiB or 8 MiB in all, a git answer larger than its cap, or a fetched repository over 256 MiB (the mirror is then removed). Point `spec.source.path` at the directory that holds the manifests, and keep large files out of it.
`DX-1604`	invalid argument	stack	1	the plan carries an action the safety policy blocks — nothing was applied The commit planned an action the source's `spec.safety` does not allow: `Adopt`, `Replace` or `Reboot` not in `allow`, a `Conflict` with another stack, or more prunes than `maximumDeletes`. A pass applies the whole plan or none of it. If the action is wanted, allow it on the node (`spec.safety.allow`, `prune`, `maximumDeletes`) and apply the source; otherwise revert the commit.
`DX-1701`	invalid argument	cluster	1	unknown cluster CNI `spec.cni` (or `--cni`) names the pod network the engine installs on the cluster's nodes. The values that exist are `default` (the engine's own: kindnet in kind mode, a node-local bridge on a one-node kubeadm cluster), `none` (install nothing; the operator applies their own) and the selectable profiles `cilium`, `calico` and `flannel`, each pinned to a version and an artefact digest. Any other value used to install nothing and say nothing, which leaves every node `NotReady`. Use one of `default`, `none`, `cilium`, `calico`, `flannel`. `delonix cluster network profiles` prints each one with its pinned version and support level; to run a CNI this engine does not ship, use `none` and apply its manifest after the cluster is up.
`DX-1702`	invalid argument	cluster	1	a network option the chosen profile does not read A field of `spec.network` was set to something the chosen pod-network profile does not render: a `dataplane` outside the profile's modes, a `kubeProxy` mode it does not implement, an extension (`hubble`, `multus`) that needs a different primary CNI or a combination that was never measured, an interface name outside the kernel's own limit, or any knob at all on `cni: default`/`cni: none`, which install no add-on and would ignore it. Routed dataplanes (`native`, BGP) are absent on purpose: they need the network around the cluster to carry pod routes, which this engine does not configure and will not assume. The message names the field and lists the values the profile accepts. Remove the field, or choose a profile that reads it.
`DX-1703`	invalid argument	cluster	1	the pod MTU does not fit the encapsulation `spec.network.mtu` is outside the 1280-9000 range, or it does not leave room for the chosen encapsulation on the node's own MTU (VXLAN and Geneve take 50 bytes, IP-in-IP 20). An MTU that does not fit does not fail: the dataplane comes up and silently drops the large packets, which reads as unexplained slowness rather than as an error — the same trap `docs/guia-rede.md` already records for this engine's own encrypted overlay. Omit `spec.network.mtu` and let the bootstrap compute it from the node MTU and the encapsulation, or set it to at most `nodeMtu` minus the overhead the message names. If the nodes do not run at 1500, declare the real value in `spec.network.nodeMtu`.
`DX-1704`	invalid argument	cluster	1	the cluster CIDRs conflict with each other or with the environment `spec.podSubnet` and `spec.serviceSubnet` overlap one another, or one of them overlaps a network this host already uses, or the pod CIDR is too small for the number of nodes (the controller-manager carves a /24 per node, so the later nodes would get no range and their pods would stay Pending). A CIDR field may also carry bits outside its own prefix (`10.244.0.1/16`), which is refused rather than masked so that the manifest and the cluster cannot disagree about what was asked. Until this code existed the CIDR fields were validated by CHARACTER SET only — `9`, `1.2.3.4` and `0.0.0.0/99` all passed, and the failure arrived later, from `kubeadm`, on a host. Pick ranges that do not overlap each other or the host's own networks (`delonix network ls` shows them), and widen the pod CIDR to at least 256 addresses per node. Nothing is created when this is refused.
`DX-1705`	invalid argument	cluster	1	the chosen pod-network profile is experimental The profile is implemented and its artefact is pinned and verified, but it has NOT been validated end to end against this engine's CRI in a multi-node topology — ADR-0074's own «what was not measured» section says so in writing. Enabling it by default would be the «reports success, does nothing» failure this project refuses, so it is gated behind an explicit opt-in instead of being hidden or removed. To use it anyway, say so in the manifest (`spec.network.experimental: true`) or on the command line (`--experimental-cni`), and read `docs/network-compatibility.md` for exactly what has and has not been measured. The refusal names the reason for that specific profile.
`DX-1706`	invalid argument	cluster	1	a network feature the cluster path does not implement yet The manifest asked for something this bootstrap does not do yet — today that is any `spec.network.ipFamily` other than `ipv4`: the cluster path renders IPv4 pod and service CIDRs only, and its CIDR validation is IPv4 arithmetic. This is «not implemented», not «impossible»: ADR-0065 carries the IPv6 dataplane and the work is real, it has simply not reached this path. Leave `spec.network.ipFamily` unset (or `ipv4`). For a dual-stack cluster today, bootstrap with `cni: none` and apply your own CNI with its own dual-stack configuration.
`DX-1707`	invalid argument	cluster	1	a field of the kind config this engine does not honour A `kind.x-k8s.io/v1alpha4` config (`delonix cluster create --config`, or `cluster apply` of such a document) was accepted field by field: delonix honours what it can implement natively (`nodes[].role`, `name`, `networking.podSubnet`, `networking.serviceSubnet`, `networking.apiServerPort`, `networking.disableDefaultCNI`) and refuses the rest BY NAME rather than warning and ignoring it — a field that reads as applied and was not is the silent-failure this engine does not ship. The refused set is the one with no equivalent in delonix's native kind mode: node `extraMounts`/`extraPortMappings` (the nodes are not Docker containers with kind's port/volume plumbing), `kubeadmConfigPatches`/`kubeadmConfigPatchesJSON6902` and `containerdConfigPatches*` (delonix writes its own rootless kubeadm/containerd config), `featureGates`, `runtimeConfig`, and `networking` knobs it does not render (`kubeProxyMode`, `apiServerAddress` other than loopback, `ipFamily` other than `ipv4`). An unrecognised key (a typo) is refused the same way. Remove the named field from the config, or drop to `delonix cluster create` flags for what delonix supports. For a feature delonix does not implement, create the cluster with `networking.disableDefaultCNI: true` (or `--cni none`) and apply your own configuration after it is up. Nothing is created when this is refused.
`DX-1801`	invalid argument	security	1	invalid secret name A secret name may only use lowercase letters, digits, dot, dash and underscore, up to 64 characters. Pick a name made of [a-z0-9._-].
`DX-1802`	invalid argument	security	1	invalid secret key A secret key must be a valid environment variable name: a letter or underscore, then letters, digits or underscores. Rename the key, for example DB_PASSWORD.
`DX-1803`	invalid argument	security	1	invalid credential name A credential name may only use lowercase letters, digits, dot, dash, underscore and colon. Pick a name made of [a-z0-9._:-].
`DX-1804`	invalid argument	security	1	corrupted master key The host's master key file has the wrong size, so nothing encrypted with it can be read. Restore the key from a node snapshot (`delonix system snapshot restore`); without it the encrypted secrets are lost.
`DX-1805`	invalid argument	security	1	the secret vault could not encrypt or decrypt Encryption or decryption failed: a blob that is corrupt, or a key that is not the one it was sealed with. Check the master key is the host's own; recreate the secret if its file is corrupt.
`DX-1901`	invalid argument	host	1	AppArmor profile unavailable The requested AppArmor profile could not be loaded: AppArmor is not enabled on this host, apparmor_parser is not on PATH, or it refused the profile. Enable AppArmor on this host, install apparmor_parser, or pass --security-opt apparmor=unconfined.
`DX-1902`	invalid argument	host	1	no CDI spec found A --gpus/--device request named a CDI-qualified device, but this host has no generated CDI spec at all. Generate one with `nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml` (installing nvidia-container-toolkit first if needed).
`DX-1903`	invalid argument	host	1	the socket passed by the service manager cannot be served The node API was started by socket activation (`LISTEN_PID` names it) and what it was passed is not one listening unix stream socket: `LISTEN_FDS` does not read as a count, more than one socket was passed, or the descriptor is a TCP port, a datagram socket or a connection instead of a listener. Serving it anyway would lose the local-socket and `SO_PEERCRED` guarantees, or serve a socket nobody asked for. Fix the `.socket` unit: one `ListenStream=` with an absolute path, `Accept=no`, `SocketMode=0600`. `delonix serve node-api --install-units` writes a correct pair.
`DX-1904`	invalid argument	host	1	--addr was given to a socket-activated node API The service manager passed a listening socket and the command line also names one with `--addr`. They are two different sockets; serving either one silently would leave the other's clients unanswered. Drop `--addr` from the unit's `ExecStart=`: under socket activation the address is the `.socket` unit's `ListenStream=`.
`DX-2000`	invalid usage	engine	2	invalid usage The command line does not parse: an unknown subcommand, a missing argument or a flag this command does not take. Run the command with --help and follow its usage line.
`DX-2601`	invalid usage	stack	2	the plan has changes `stack plan --detailed-exitcode` found differences between the manifest and what is running. Not a failure. Review the plan, then run `delonix stack apply` if the changes are wanted.
`DX-3000`	not running	engine	3	not running The resource exists but is not running, and the operation needs it running. Start it (`delonix container start <name>`, `delonix vm start <name>`) and try again.
`DX-3101`	not running	container	3	container is not running The container exists, but the operation needs it running. Start it first (`delonix container start <name>`).
`DX-4000`	not found	engine	4	no such resource Nothing with that name or id exists in this scope. Check the name and the namespace with the matching `ls`, or create the resource first.
`DX-4001`	not found	engine	4	no such route on the node API The request reached the node API socket on a method and path it has no handler for. The published OpenAPI (`GET /openapi.json`) lists the contract; a path there may still be one this engine version does not serve (DX-6001). Check the method and the path against `GET /openapi.json`, or open `GET /docs`.
`DX-4101`	not found	container	4	no such container No container answers to that id, id prefix or name in this state root. List them with `delonix container ps -a`.
`DX-4102`	not found	container	4	CDI device not found The device name is not declared by any discovered CDI spec. Check the device name against the spec (`nvidia-ctk cdi list`), or regenerate it.
`DX-4201`	not found	volume	4	no such volume There is no volume with that name in this scope. List them with `delonix volume ls` (-A for every namespace), or create it with `delonix volume create`.
`DX-4202`	not found	volume	4	no such snapshot The volume has no snapshot with that name. List its snapshots with `delonix volume snapshot ls <volume>`.
`DX-4203`	not found	volume	4	no such storage pool No `kind: StoragePool` with that name is in use on this node. The administrator's allowlist says which pools may be used; a pool is used once a `kind: StoragePool` names it. List them with `delonix get storagepools`, and apply a `kind: StoragePool` with that name.
`DX-4301`	not found	network	4	no such NetworkRoute There is no NetworkRoute between the given pair of networks. List routes with `delonix network route ls`, or create one with `delonix network route <from> <to>`.
`DX-4302`	not found	network	4	no such Service There is no Service of that name in that namespace. List services with `delonix get services`.
`DX-4303`	not found	network	4	ingress network does not exist The named network has no NetDef on this holder — it was never realized here, or was removed. Create it with `delonix network create <name>`, or use the default network.
`DX-4304`	not found	network	4	no such OPNsense API route The appliance answered HTTP 404 `{"errorMessage":"Endpoint not found"}` — the module/controller/command path does not exist on this OPNsense version. Check the path against `docs.opnsense.org/development/api.html` for the appliance's own version.
`DX-4401`	not found	image	4	no such image The image is not in the local store and the registry has no such tag. Check the reference, or pull it first (`delonix image pull`).
`DX-4402`	not found	image	4	image or repository not visible The registry does not show the repository or image to these credentials: it does not exist, or it is private. Log in with credentials that can see it (`delonix image login <registry>`).
`DX-4501`	not found	vm	4	no such VM There is no virtual machine with that name in this state root. List them with `delonix vm ls`, or create it with `delonix vm create`.
`DX-4502`	not found	vm	4	no such snapshot The VM has no snapshot with that name. List its snapshots with `delonix vm snapshot ls <vm>`.
`DX-4503`	not found	vm	4	no such snapshot The VM has no snapshot with that name on the Proxmox node. List its snapshots with `delonix vm snapshot ls <vm>`.
`DX-4504`	not found	vm	4	no such resource on the Proxmox node The node answered HTTP 404, or reported that the VM's configuration file does not exist (which it says with HTTP 500). Check the VM id in the record against `qm list` on the node; a VM removed on the node side leaves a record with nothing behind it.
`DX-4505`	not found	vm	4	no such network for the VM The VM names a network that is not declared on this node. The create stopped before building anything. Create it first with `delonix network create <name>` (or a `kind: Network`), or leave `--network` out for the default network.
`DX-4601`	not found	stack	4	no such GitOps source There is no `kind: GitOpsSource` with that name in that namespace on this node. List them with `delonix get gitopssources`; a source is registered with `delonix stack apply`.
`DX-4801`	not found	security	4	no such secret There is no secret with that name. List them with `delonix secret ls`, or create it with `delonix secret create`.
`DX-5000`	conflict	engine	5	conflict: already exists The name is already taken, or the desired state conflicts with what is there. Pick another name, remove the existing resource, or use the command's --force/--replace if it has one.
`DX-5001`	conflict	engine	5	request_id reused for a different request The node API's operation ledger answers a retried mutation with its first recorded result (ADR-0042 D2 "Idempotency"), identified by request_id, verb and target. This request_id already produced an operation for the same verb and target, but its recorded request does not match this one's content (image, size, namespace or similar fields differ) — a request_id names one exact request, not a resource. Generate a new request_id (an idempotency key is meant to be unique per distinct request, e.g. a fresh UUID per call site), and send the two requests with their own keys.
`DX-5002`	conflict	engine	5	the operation cannot be cancelled The operation already ended, or it is running past its point of no return: every mutation this engine serves on the node API runs to its end once acknowledged, so nothing was cancelled and the operation's state is unchanged. Watch the operation to its end (`WatchOperation`, or `GET /v1/operations/{id}`), then undo what it did with the inverse request if that is what you wanted.
`DX-5101`	conflict	container	5	container already running The container is running, and the operation would remove or replace it without --force. Stop it first, or pass --force.
`DX-5201`	conflict	volume	5	the storage pool holds something that stands in the way The pool still holds volumes of this engine, or the object a driver was asked to create or release exists in the pool without this engine's stamp for this state root. An object is never adopted or deleted by its name (ADR-0067 D5). Remove the volumes the message lists first; for an object that is not this engine's, pick another volume name or have its owner remove it.
`DX-5202`	conflict	volume	5	the storage pool cannot take this volume The sum of the sizes allocated in the pool would pass its over-allocation ceiling (`overcommit.maxRatio` times its capacity), or the pool is already above 95% full (ADR-0067 D6). Free space in the pool, ask for a smaller volume, or raise `overcommit.maxRatio` in the `kind: StoragePool` knowing a full pool fails every volume in it.
`DX-5203`	conflict	volume	5	volume is in use A container mounts the volume, or a share is carved out of its data, and removing it would take their data from under them. Remove what the message lists first (`delonix container rm`, `delonix volume rm <share>`), or ask for the removal with force to destroy the data anyway.
`DX-5204`	conflict	volume	5	the storage pool was not created by this helper `destroy-pool` destroys only a pool the administrator's allowlist marks with a `create:` block and that carries the helper's own creation mark. A pool that existed before the engine, or one whose mark is missing, is never destroyed (ADR-0067 D5). Remove the pool's entry from `/etc/delonix/storage-pools.yaml` to stop using it; destroying what backs it is the administrator's own decision, outside this engine.
`DX-5205`	conflict	volume	5	a device named for the pool cannot be used `create-pool` was refused before it wrote anything: a device in the pool's `create.devices` carries a filesystem or volume signature, does not resolve to a block device, or the volume group, zpool or mount point it would create already exists. Check the device the message names. To overwrite a signature, pass `--wipe-devices` at the terminal, knowing it destroys what is on the device.
`DX-5301`	conflict	network	5	network already exists A NetworkStore network with that name already exists. Pick another name, or remove the existing one first (`delonix network rm <name>`).
`DX-5302`	conflict	network	5	no free subnet left The workload address space has no /16 left to hand a new network. Remove an unused network (`delonix network rm <name>`) to free a /16.
`DX-5303`	conflict	network	5	subnet overlaps an existing network The requested CIDR overlaps an existing network's subnet. Pick a CIDR that does not overlap any network `delonix network ls` already shows.
`DX-5304`	conflict	network	5	network subnet cannot be changed in place A network by this name already exists with a different subnet than the one asked for; workloads may already be addressed on it. Remove the network (`delonix network rm <name>`) and create it again with the new subnet.
`DX-5305`	conflict	network	5	base octet already used by another network The /16 a create_with_base call was given is already used by a different network. Pick a different base octet, or remove the network that already has it.
`DX-5306`	conflict	network	5	ingress network already realized on a different prefix An ingress NetDef is already realized on a prefix different from the one the registry now asks for. Remove the network (`delonix network rm <name>`) and create it again, or keep the recorded subnet.
`DX-5307`	conflict	network	5	network is in use The network still has containers, pod members or VMs attached, and removing it would leave them addressed on a bridge that no longer exists. Remove or disconnect what the message lists (`delonix container rm`, `delonix network disconnect`, `delonix vm rm`), then remove the network.
`DX-5308`	conflict	network	5	address already taken The address asked for is already leased to another container, or it belongs to the pool the network's DHCP server hands to VMs. Pick another address (`delonix network ipam ls` shows the leased ones), or leave the address to the engine.
`DX-5360`	conflict	network	5	VIP pool overlaps an address range in use The VIP pool shares addresses with something this node routes or serves: an engine network, a CNI pod range, a kind cluster's pod or service subnet, a host address or route (a VPN included), or the holder's own subnets (ADR-0066 D2). A VIP there would shadow real addresses. Choose a pool nothing on this node uses (`delonix network vip-pool set <cidr>`); the message names the overlapping source.
`DX-5389`	conflict	network	5	the network provider holds something this engine will not overwrite The remote provider (an OPNsense appliance, a Proxmox cluster's SDN) has an object with the identity being ensured or removed and no owner mark of this engine (someone else's: never adopted by name, never deleted); or an object this engine created was edited there and no longer matches the manifest (there is no update in place); or it has staged changes that are not this engine's, and its commit applies everything staged at once. ADR-0059 D5 reason `provider_conflict`. The owner mark is a firewall category named `delonix-owner:<token>` (OPNsense) or `[delonix-owner:<token>]` at the end of a vnet alias (Proxmox). Read which of the three the message names: rename the object or remove the stale one on the provider; put an edited object back as declared, or replace it (`delonix stack apply --replace <Kind>/<name>`); or have whoever staged the other changes apply or discard them. Then apply again.
`DX-5390`	conflict	network	5	the plan was computed against a state that has changed since `stack apply --plan-digest` was given a digest, and the digest recomputed now for a network document is not among the ones given: the manifest, what the provider holds, the provider, its capabilities or the catalog changed between the plan and the apply. ADR-0059 D5 reason `stale_plan`. Nothing was written. Plan again (`delonix stack plan -o json`), read what changed, and apply with the new `planDigest`.
`DX-5501`	conflict	vm	5	VM name already used by another VM subsystem A VM record under this name already exists, created by the other (direct-QEMU) VM subsystem that shares the same vms/ folder. Remove it first (`delonix vm rm <name>`), or pick another name.
`DX-5502`	conflict	vm	5	VM snapshot name already used The VM already has a snapshot with that name. Pick another name, or remove the existing snapshot (`delonix vm snapshot rm`).
`DX-5503`	conflict	vm	5	snapshot name already used The VM already has a snapshot with that name on the Proxmox node. Pick another name, or remove the existing snapshot first.
`DX-5504`	conflict	vm	5	the Proxmox node reports a conflict The node answered HTTP 409, or reported that the resource already exists (which it says with HTTP 500). Pick another name or id, or remove what is already there.
`DX-5505`	conflict	vm	5	the VM must be stopped to resize it `vm resize` is a cold resize: it changes the definition a VM boots with. A running or paused guest would not see the change until its next reboot, so the verb refuses instead of reporting a resize that has not happened. Run `delonix vm stop <name>`, resize, then `delonix vm start <name>`.
`DX-5506`	conflict	vm	5	the VM must be stopped to change its cloud-init The guest reads cloud-init at boot: a running or paused VM would keep the old hostname and keys until its next reboot, so the verb refuses instead of reporting a change that has not reached the guest. Run `delonix vm stop <name>`, change it, then `delonix vm start <name>`.
`DX-5507`	conflict	vm	5	the VM cannot be moved as asked `vm move` was refused before it started: the VM is in the wrong power state for the move asked (`--live` needs it running, a move without `--live` needs it stopped), or the node's own precheck says the target cannot host it — local disks the target would have to copy, a storage the target does not have, or a local device. Stop or start the VM to match `--live`; for a precheck refusal, put the VM's disks on a storage the whole cluster shares, or remove the local device.
`DX-5508`	conflict	vm	5	the hypervisor's network is not on the declared subnet The hypervisor already has a network with the name the VM asked for, on a different subnet than the one declared for it. The engine redefines such a network only when it defined it itself and no VM is on it; otherwise it refuses, because attaching the VM would put it on a subnet nobody declared. Remove the VMs still on the old network first, or give the delonix network another name. A network the engine did not define is the operator's: change or remove it with `virsh net-edit`/`virsh net-undefine` if that is what you want.
`DX-5515`	conflict	vm	5	the cluster's SDN configuration is locked Proxmox VE has one global lock over the SDN configuration (`POST /cluster/sdn/lock`). While another holder has it, every staged SDN write and the apply are refused; the node also says this when the token this client carried is no longer the lock's. Wait for the holder to apply or roll back; if the holder is gone, release the lock with its token (`DELETE /cluster/sdn/lock`), or with `force=1` once you are sure nobody is using it.
`DX-5516`	conflict	vm	5	the cluster has pending SDN changes The SDN lock was refused because the cluster already carries staged SDN changes nobody applied. Taking the lock anyway and applying would push that other work along with this change. Find who staged them (`delonix`'s pending-change list, or the node's SDN panel) and have them applied or rolled back first.
`DX-5517`	conflict	vm	5	the system container cannot be moved as asked `systemcontainer move` was refused before anything moved: the container is running and `--restart` was not given (the node cannot move a running container live), its volumes are on a storage the target does not share and `--with-local-disks` was not given (the node would copy them in full), or the node's own precheck does not list the target. Pass `--restart` to stop it, move it and start it on the target, or `--with-local-disks` to let the node copy its volumes, or pick a node the precheck allows.
`DX-5601`	conflict	stack	5	a resource the manifest declares is held by someone else — nothing was changed The plan holds a `Conflict`: a resource of this name already carries another stack's `delonix.io/stack` stamp, or (a VM) the provider holds one this node's registry does not know. Two stacks converging one resource would flap it between two shapes on every apply, so `stack apply` refuses the whole apply before anything is touched, `stack apply --dry-run` exits with this code after printing the manifest, and `stack plan --detailed-exitcode` exits with it instead of 0 or 2. No flag authorises it. Apply it from the stack that owns it, remove it there first, or rename it in this manifest; `stack plan` names the owner.
`DX-6000`	unavailable	engine	69	unavailable on this host A tool, a backend or a kernel feature the operation needs is not present. Nothing about the arguments is wrong. Install what the message names (`delonix system info` shows what this host has) and run the command again.
`DX-6001`	unavailable	engine	69	the node API does not serve this yet The operation is in the contract (`proto/delonix/node/v1`) and this engine version does not serve it: the message names the ADR step that brings it. The HTTP status is 501 Not Implemented, not 503: retrying will not help. Use the CLI for the operation meanwhile, or an engine version that serves it (`GET /v1/node` gives the version).
`DX-6101`	unavailable	container	69	container has not finished mounting The container's process runs, but its start passed the mount ceiling before the init said its filesystem was in place, so a command entering it now could run on the host's filesystem. Commands that enter it are refused until the init says so. Wait and retry: the refusal lifts on its own once the mounts finish. If it never does, look at the volumes it mounts (an unresponsive NFS server is the usual cause) and restart the container.
`DX-6102`	unavailable	container	69	the container's cgroup group could not be created or limited As root, a container that names a cgroup group is placed under `delonix.slice/<group>/`, and the group's aggregate ceiling is written before the container joins. Creating the group, writing one of its ceilings, or handing a controller down to it failed — and a group without its ceiling would hold nothing, so the container is not started. Read the message for the file and the error. Check that `delonix.slice` hands down the `memory`, `cpu` and `pids` controllers (`delonix system doctor`), and that no other process sits directly in the group's directory.
`DX-6201`	unavailable	volume	69	could not build the TrueNAS HTTP client The local TLS/HTTP stack could not build a client for the request. Nothing about the manifest is wrong. Check the host's TLS libraries; `delonix system info` reports what this host has.
`DX-6202`	unavailable	volume	69	unsupported TrueNAS version This build only speaks one TrueNAS REST API major; the surface moves between majors. Point the manifest at a TrueNAS SCALE appliance on the supported major, or update this engine.
`DX-6203`	unavailable	volume	69	the storage pool cannot be used on this host No allowlist of storage pools exists on this node, the pool's driver is not built in this version, or the probe found the backing object missing or not writable. Nothing was created. Follow the remedy in the message: have the administrator declare the pool in `/etc/delonix/storage-pools.yaml`, create its directory, or give this user write access to it.
`DX-6204`	unavailable	volume	69	the state of the storage pool could not be determined The listing that would say whether the pool is usable needs a privilege this process does not have, or the allowlist could not be read. An empty answer obtained without the privilege to list is never read as «no pools» (ADR-0067 D3.5). Follow the remedy in the message; nothing was created or changed.
`DX-6205`	unavailable	volume	69	this process cannot remove the volume's data Some of the volume's data is owned by a mapped subuid (written by a container in a user namespace), and the node API has no way into that user namespace yet; removing what it can read would leave the volume half deleted. Nothing was removed. Remove it with `delonix volume rm <name>`, which removes mapped data from inside the user namespace that owns it.
`DX-6206`	unavailable	volume	69	the privileged storage helper cannot be reached The pool's driver needs an operation only root can do (LVM-thin, a ZFS mount), and neither the socket-activated helper nor an in-process root engine is configured on this node. Nothing was created (ADR-0067 D3). Install the helper units and enable `delonix-storage-helper.socket`, and add this user to the pool's `allowUsers`; or run the engine as root with `mode: in-process` in the allowlist.
`DX-6301`	unavailable	network	69	'wg' is not available on this host WireGuard node keys and encrypted overlay networks need the `wg` binary, which is not on PATH. Install wireguard-tools (Debian/Ubuntu: apt install wireguard-tools; Fedora/RHEL: dnf install wireguard-tools; Arch: pacman -S wireguard-tools).
`DX-6302`	unavailable	network	69	this management API route no longer changes the network The route wrote the dataplane without the container's record, so the next reapply undid it and a multi-homed workload kept its other addresses open. The management API is frozen (ADR-0041 D4) and refuses instead of writing half a policy. Use the CLI, which goes through the record: `delonix net ingress`/`net egress` for firewall and egress, `delonix network connect`/`disconnect` for extra networks, `delonix container rm`/`stop` to detach.
`DX-6305`	unavailable	network	69	namespace isolation would not be enforced on this host A named namespace was asked for, but the kernel is not filtering traffic inside a bridge (br_netfilter not loaded, or net.bridge.bridge-nf-call-iptables=0). Every isolation rule would install and none would block anything. Load br_netfilter and set bridge-nf-call-iptables=1 (`delonix system doctor` prints the commands, `install.sh --tune` persists them), or set DELONIX_ALLOW_UNENFORCED_ISOLATION=1 to run without isolation on purpose.
`DX-6360`	unavailable	network	69	no VIP pool configured A Service with `type: VirtualIP` was applied on a node with no VIP pool. There is no default pool on purpose: a universal reservation would take a range away from every host this engine runs on (ADR-0066 D2). Configure one with `delonix network vip-pool set <cidr>` (or `DELONIX_SERVICE_VIP_CIDR` for one process), or use `type: DNS`.
`DX-6361`	unavailable	network	69	VIP hairpin needs br_netfilter Bridged traffic does not pass through netfilter in the holder (`net.bridge.bridge-nf-call-iptables` is not 1, or `br_netfilter` is not loaded), so a client on its backends' own network would time out on the VIP (ADR-0066 D5). Load the module on the host (`modprobe br_netfilter`); `install.sh` does it by default.
`DX-6381`	unavailable	network	69	no registered provider serves this network capability The provider that would serve the request is not registered for its role, or does not implement the operation: a document names one that is not registered, networkDefaults.<role> names one, or a resource's record names the provider that created it and that provider is not registered now. A default is never skipped to try another provider, and a recorded resource never moves (ADR-0059 D3). ADR-0059 D5 reason `unsupported_capability`: the remedy is another provider, not another argument. Configure the provider the message names (`delonix provider ls` lists what is registered), or name one that serves the role.
`DX-6383`	unavailable	network	69	the network provider could not be reached The request to the remote network provider (an OPNsense appliance) could not be sent or was not answered: connection refused, DNS, TLS, or a connection dropped mid-answer. When it dropped after a write was sent, whether the write landed is unknown; the next plan reads the provider again. ADR-0059 D5 reason `provider_unavailable`. Check that the provider's url in providers.yaml answers from this host, then plan and apply again.
`DX-6501`	unavailable	vm	69	VM backend not configured This build knows about the named backend, but nothing in this process has configured it (e.g. Proxmox with no target set). Configure it as the message describes, or use a backend that is already available.
`DX-6502`	unavailable	vm	69	no VM backend available Auto-detection found neither Cloud Hypervisor nor libvirt+qemu installed. Install cloud-hypervisor or libvirt+qemu.
`DX-6503`	unavailable	vm	69	no VM firmware found Booting a cloud image on Cloud Hypervisor without an explicit kernel needs a firmware, and none was given or found bundled. Reinstall (curl install.sh) to fetch rust-hypervisor-fw, pass --firmware <path>, or use --backend libvirt.
`DX-6504`	unavailable	vm	69	cloud-localds not found Generating a cloud-init NoCloud seed needs the cloud-localds tool, which is not on PATH. Install it (Debian/Ubuntu: cloud-image-utils, Fedora/Rocky: cloud-utils), or pass a ready-made seed.
`DX-6505`	unavailable	vm	69	could not build the Proxmox HTTP client The local TLS/HTTP stack could not build a client for the request. Nothing about the manifest is wrong. Check the host's TLS libraries; `delonix system info` reports what this host has.
`DX-6506`	unavailable	vm	69	Proxmox node unavailable The node answered HTTP 502/503/504: the API is up but cannot serve the request right now (pveproxy without a backend, node restarting). Retry later; check the node's services (`pveproxy`, `pvedaemon`) and the cluster's quorum.
`DX-6507`	unavailable	vm	69	capability not supported by the backend The backend this VM would run on does not mark a required capability usable on this host — or, with auto-detection, no available backend does. The message lists each unmet entry with the provider's own state and reason. It is the node contract's FAILED_PRECONDITION with reason CapabilityNotSupported (ADR-0050 D6). Pick a backend that has it (`delonix provider ls`, `--backend`), fix what the host lacks when the state is `unavailable-on-host`, or drop the requirement.
`DX-6508`	unavailable	vm	69	the Proxmox datacenter firewall is off A `NetworkPolicy` with `scope: vm` asked for rules on a VM of a Proxmox cluster whose datacenter-level firewall is disabled. With it off, no rule of any VM filters anything, so applying the policy would report protection that does not exist (ADR-0052). The engine never turns it on: that also changes what the cluster's own nodes accept. Enable the firewall at Datacenter level on the cluster (Datacenter › Firewall › Options, or `pvesh set /cluster/firewall/options --enable 1`), after checking the management rules for the nodes, then apply again.
`DX-6509`	unavailable	vm	69	the backup could not be taken with the guest's filesystem frozen A quiesced backup freezes the guest's filesystems through the QEMU guest agent for the instant the disk is copied, so the archive holds a consistent filesystem. The guest was not running, its agent did not answer, or the node's own backup log did not show the freeze and the thaw — and a backup that cannot be shown to be quiesced is not reported as one. Install and start `qemu-guest-agent` in the guest and set `agent=1` on the VM; for a stopped VM, a plain backup is already consistent.
`DX-6510`	unavailable	vm	69	the node's import storage does not accept images A Proxmox VM created from a local image is uploaded to a dir storage of the node under `import/`, and the node accepts that only on a storage whose content types include `import` (ADR-0057). The engine never changes a storage's content types: that is administering the node. Enable it on the node (`pvesm set <storage> --content <current types>,import`, or Datacenter › Storage › Edit › Content), or point `DELONIX_PROXMOX_IMPORT_STORAGE` / `storage.import` in providers.yaml at a storage that has it.
`DX-6511`	unavailable	vm	69	the node's import storage has no room for the image The image would be uploaded to the node's import storage, and that storage has less free space than the image. The upload is refused before it starts, because the node's own refusal would come after the bytes had been sent. Free space on the storage, or point `DELONIX_PROXMOX_IMPORT_STORAGE` / `storage.import` in providers.yaml at a storage with room.
`DX-6512`	unavailable	vm	69	the SDN apply ended OK but a node did not realize it An apply of the cluster's SDN configuration (`PUT /cluster/sdn`) forks one `reloadnetworkall` task, and that task ends OK when the entry node's reload succeeds — even if another node's reload failed. The engine then reads each online node's zone content, and at least one vnet was not `available` there. The message names each node, zone and vnet with the node's own reason. Read that node's 'reload network' task log (`pvesh get /nodes/<node>/tasks --typefilter srvreload`), fix what it names — commonly the `dnsmasq` package for a zone with `dhcp=dnsmasq`, or the `source /etc/network/interfaces.d/*` line in `/etc/network/interfaces` — and apply again.
`DX-6513`	unavailable	vm	69	the node's storage does not accept container archives A system container on a Proxmox node is created from an OCI archive the engine uploads to a storage of the node as a container template, and the node accepts that only on a storage whose content types include `vztmpl` (ADR-0058). The engine never changes a storage's content types: that is administering the node. Enable it on the node (`pvesm set <storage> --content <current types>,vztmpl`, or Datacenter › Storage › Edit › Content), or use a storage that has it.
`DX-6514`	unavailable	vm	69	the node's storage has no room for the container archive The container archive would be uploaded to a storage of the node, and that storage has less free space than the archive. The upload is refused before it starts, because the node's own refusal would come after the bytes had been sent. Free space on the storage, or use a storage with room.
`DX-6515`	unavailable	vm	69	the VM's CPU and memory ceilings cannot be enforced A Cloud Hypervisor VMM starts inside its own cgroup leaf, with the VM's CPU and memory as the leaf's ceilings, so the process that holds the vCPUs and the guest's RAM is the one limited. No leaf can exist for it on this host (rootless without a delegated cgroup, or no leaf provider in this process), or a ceiling did not land on the leaf. Nothing was created. Run the engine where it can create cgroups: as root, or rootless under a delegated scope (`systemd-run --user --scope -p Delegate=yes -- delonix vm create ...`). To start the VM without ceilings on purpose, set DELONIX_ALLOW_UNENFORCED_LIMITS=1.
`DX-6601`	unavailable	stack	69	git is not installed A GitOps pass fetches with the system's `git(1)` (ADR-0021 decision 2: a subprocess, not a library), and this node has none on `PATH`. Install the `git` package (`apt install git`, `dnf install git`).
`DX-6602`	unavailable	stack	69	the source could not be fetched `git fetch` of the source's ref failed: the remote is unreachable, the ref does not exist, the key or the pinned host key was refused, or git refused the objects (`fsckObjects`). Nothing was read and the running stack is untouched. Check the URL and the ref, that the node reaches the remote, and that the deploy key and the pinned host keys in the named secrets are the right ones.
`DX-6603`	unavailable	stack	69	the GitOps timer could not be installed A source with `sync.automated: true` installs a systemd timer, and `systemctl` is missing or refused (no user manager in this session, for a rootless node). Run it where systemd manages the user (`loginctl enable-linger`), or set `sync.automated: false` and run `delonix gitops reconcile` from your own scheduler.
`DX-6701`	unavailable	cluster	69	RETIRED — the default CNI of a multi-node kubeadm cluster is no longer refused No longer raised (kept so `explain DX-6701` stays honest for older output). A kubeadm cluster with more than one node and `cni: default` was once refused here, because the default CNI was a node-local bridge that routes nothing between nodes. The engine now RESOLVES `default` to Cilium on that path (`net_profiles::resolved_profile`), the HA default cross-node pod network — a single node still gets the bridge, and `mode: kind` still gets kindnet. See ADR-0078 (amended 2026-10-27). Nothing to do: `cluster kubeadm` with several nodes and `cni: default` now brings up a working Cilium cluster on its own. To pick a different pod network, pass `--cni cilium\|calico\|flannel` (with `--experimental-cni`) or `--cni none` to apply your own.
`DX-6702`	unavailable	cluster	69	two or more cluster nodes resolved to the same address Every machine of a kubeadm cluster was provisioned, but two or more of them resolved to the SAME address, so the bootstrap would open one SSH session per node and several would land on one machine while the rest were never configured. The usual cause is a golden image that ships a baked-in identity: `/etc/machine-id` is non-empty inside the image, every clone derives the same systemd DHCP client identifier from it (DUID-EN, enterprise number 43793), and a DHCP server keys its leases by client identifier when one is present — so N clones are treated as ONE client and a single lease migrates to whichever asked last, leaving them all holding the same address. Refused here, before any host is prepared; without this check the run failed much later and much further away, as an unrelated `mv: cannot stat '/tmp/delonix-cri'` from a prep step racing itself over one host. Check it with `virsh net-dhcp-leases <network>`: one entry for N running clones, all sharing a `Client ID or DUID`, is this bug. `delonix vm image build` has emptied `/etc/machine-id` as its last step since v0.10.0 — an image built before that keeps a real one, so rebuild the image (`delonix vm image build`) and create the cluster again. For an image you did not build here, empty the file rather than deleting it (`truncate -s 0 /etc/machine-id`, zero bytes, so systemd generates one per boot) and remove any persisted DHCP lease or DUID state under `/var/lib/dhcp/` and `/var/lib/systemd/network/`.
`DX-6703`	unavailable	cluster	69	the pod network of a live cluster is not changed in place The cluster already runs one pod-network profile and the manifest now asks for another. There is no supported migration: the two profiles own the same pod CIDR, the same `/etc/cni/net.d` and the same iptables/eBPF state on every node, and nothing in this engine drains, re-addresses and re-attaches every pod. Applying the second one over the first would leave two owners of the pod network and a cluster whose behaviour depends on which agent wrote a rule last. The cluster is left untouched and still running the profile it had. Create a new cluster with the profile you want and migrate the workloads. If the goal is to repair an installation of the SAME profile, re-run the apply: that path is idempotent.
`DX-6704`	unavailable	cluster	69	the pod-network artefact could not be obtained or did not match its digest The pinned install artefact for the chosen profile (a manifest, or a Helm chart tarball) could not be downloaded, or its content did not match the SHA-256 this release pins. In offline mode it means the artefact is not in the local cache at all. Either way the bootstrap stops BEFORE applying anything: an artefact whose bytes changed is not installed on the strength of its URL. Online: check the host's own network reach to the publisher and re-run. Offline: pre-populate the cache with `delonix cluster network fetch --cni <profile>` on a machine that has reach, then copy `<root>/net-profiles/` across. A digest mismatch on a reachable publisher means this release's pin and the published artefact disagree — report it rather than working around it.
`DX-7000`	permission denied	engine	77	permission denied The operating system refused on a permission: a file, a directory or a capability. Fix the permission on the path the message names, or run from a session that has it, and repeat.
`DX-7201`	permission denied	volume	77	the administrator's allowlist does not permit this The pool is not in the administrator's allowlist of storage pools, or the volume asked for is larger than the pool's `maxVolumeBytes`. A manifest can only use what the administrator declared (ADR-0067 D3). Ask the administrator to add the pool to `/etc/delonix/storage-pools.yaml` or to raise its `maxVolumeBytes`; or use a pool `delonix get storagepools` lists.
`DX-7202`	permission denied	volume	77	the storage helper does not serve this user for this pool The helper reads the caller's uid from the socket itself (`SO_PEERCRED`) and serves only a uid the pool's `allowUsers` names. An empty `allowUsers` serves nobody. Ask the administrator to add this user to `allowUsers` of the pool in `/etc/delonix/storage-pools.yaml`.
`DX-7203`	permission denied	volume	77	a pool administration command needs root `delonix-storage-helper create-pool` and `destroy-pool` write to raw devices, volume groups and pools: they run only as root, at a terminal, never on a manifest's word. Run it with `sudo` at a terminal.
`DX-7385`	permission denied	network	77	the network provider refused the credential The remote network provider refused what it was sent: OPNsense answers 401 for a key/secret it does not accept, a 302 to its login page when no credential arrived at all, and 403 for a key without the privilege the route needs (ADR-0051 phase 0). ADR-0059 D5 reason `provider_auth_failed`. Check the key and secret files named in providers.yaml, and that the API user holds the firewall privileges on the appliance.
`DX-7601`	permission denied	stack	77	the commit is not signed by a trusted key The source asks for signed commits and `git verify-commit` did not accept the commit against the SSH `allowed_signers` in `trustedKeysRef`: unsigned, signed by another key, or signed with GPG (only SSH signatures are verified). Nothing was read from it. Sign the commit with a key listed in the trusted keys secret, or add the signer's key to it on the node.
`DX-7801`	permission denied	security	77	source-check override not granted by the node policy A container asked for an anti-spoofing exception (`--allow-source` or `--no-source-check`) that this node's runtime policy does not grant. These are permissions, not ceilings: without `allowedSourcePrefixes` / `allowSourceCheckOptOut` in the policy nothing is granted. The refusal is in the event log. Ask the node administrator to grant it in the runtime policy (`kind: RuntimePolicy`), or drop the flag. A prefix must sit inside one the policy grants.
`DX-7802`	permission denied	security	77	refused by the node's runtime policy The node's admission point (`policy.json`, `kind: RuntimePolicy`) refused the workload before anything was created: a container, pod or VM asked for something the policy forbids (privileged, host network, an unlisted registry, device passthrough, or what `workloadSecurity: baseline` refuses). Every reason is named, and the refusal is in the event log. It is a permission refusal, so it exits 77 like the other policy refusals. Drop what the policy forbids from the request, or ask the node administrator to change the runtime policy (`kind: RuntimePolicy`). `delonix describe runtimepolicies` prints what is in force.
`DX-8000`	timeout	engine	124	timed out The deadline passed with the work unfinished. Nothing said no; it may still be finishing. Wait and ask again, or raise the --timeout. Do not recreate the resource on top of one still coming up.
`DX-8101`	timeout	container	124	container still exiting after SIGKILL `rm -f` killed the container, but its process had not finished exiting when the deadline passed — usually stuck in the kernel flushing the container's filesystem to a busy disk. The container is still listed, so no live process goes untracked. Run the same `rm -f` again once the host's disk settles; it removes the container as soon as its process is gone.
`DX-8201`	timeout	volume	124	TrueNAS job timed out An asynchronous job on the appliance (permissions, dataset work) did not reach a terminal state before the deadline. It may still be finishing on the appliance; check it there before retrying.
`DX-8501`	timeout	vm	124	Proxmox task timed out A task on the node (create, start, snapshot, destroy) did not reach a terminal state before the deadline. It may still be finishing on the node; check the node's task log before retrying.
`DX-8502`	timeout	vm	124	Proxmox VM config lock stayed busy The node kept refusing because the VM's config lock was held (usually qmeventd cleaning up after a stop), past the retry window. Check the node's task log for this VM; something is still holding the lock.
`DX-8503`	timeout	vm	124	VM did not come up before the boot timeout `--wait` gave the VM the whole `--boot-timeout` and never saw it answer: no address yet, or an address that never replied. The VM is left as it is, still running. Watch the boot with `delonix vm console <name>`; raise `--boot-timeout` for a slow guest, or `delonix vm rm` it if it will not boot.
`DX-8504`	timeout	vm	124	the hypervisor assigned the resource, but the guest has not used it yet `vm update` added a vCPU or memory and the hypervisor confirmed it, but within the wait deadline the guest had not activated it (CPU onlined, memory block online) — or the backend has no channel to see the guest at all (ADR-0068 D4). The record already holds the hypervisor-assigned value: a restart will not drop it. Give the guest more time and check again with `delonix vm describe`; a guest without the onlining policy (ADR-0068 D8) may never activate it on its own.
`DX-8601`	timeout	stack	124	git did not finish in time A git invocation of a GitOps pass ran past its ceiling (120 s) and was stopped, so a hung remote does not hold the source's lock until the next fire. Check that the remote answers; the next fire tries again.
`DX-9000`	system failure	engine	1	a system call failed The kernel refused an operation (clone, mount, setns…). The message carries the operation and the errno. Read the errno in the message; `delonix system info` checks the host requirements (user namespaces, cgroup delegation).
`DX-9001`	system failure	engine	74	I/O error The filesystem said no on a path the engine needs: a full disk, a missing directory, a bad mount. Check the path in the message and the free space of the state root (`delonix system df`).
`DX-9002`	system failure	engine	1	invalid state record A state record on disk could not be read or written as JSON: it is corrupt or from an incompatible version. Inspect the record the message names; restore it from a snapshot (`delonix system snapshot restore`) if it is corrupt.
`DX-9003`	system failure	engine	1	the state lock could not be taken The lock that serialises a read-modify-write of a state record could not be opened or taken, so the write was refused rather than risk losing a concurrent one. Check the state root is writable by this user and not on a filesystem without flock.
`DX-9004`	system failure	engine	1	no entropy from the kernel The kernel did not provide random bytes, which encryption and generated values need. Check getrandom(2) works on this host (a very old kernel or a restricted seccomp profile).
`DX-9005`	system failure	engine	1	the node API failed while answering The node API could not compute its answer: a probe it runs panicked or a value it reads could not be produced. The message carries what failed. Read the message; the server's log (`delonix serve node-api`) has the detail. Report it if it repeats.
`DX-9201`	system failure	volume	1	a storage tool failed A host tool the volume needs (mount, mkfs.ext4, resize2fs, losetup…) failed or is missing. The message carries its own error. Read the tool's error in the message; mounting network volumes and hard quotas need CAP_SYS_ADMIN.
`DX-9202`	system failure	volume	1	TrueNAS request failed The HTTP request to the appliance could not be sent or answered (network, TLS, DNS). Check the target url and that the appliance is reachable from this host.
`DX-9203`	system failure	volume	1	TrueNAS answered with an HTTP error The appliance's REST API returned a non-2xx status; the message carries its own error body. Read the body in the message — TrueNAS puts the actionable detail there.
`DX-9204`	system failure	volume	1	could not read the TrueNAS response The appliance's answer was not the JSON this client expected. Check the appliance is on the supported major; the message carries the start of the body.
`DX-9205`	system failure	volume	1	TrueNAS job failed An asynchronous job on the appliance finished FAILED or ABORTED; the message carries its own reason. Read the appliance's reason in the message.
`DX-9206`	system failure	volume	1	TrueNAS job vanished The appliance stopped reporting a job before it reached a terminal state, so whether the work happened is unknown. Check the dataset/permissions on the appliance directly.
`DX-9207`	system failure	volume	1	TrueNAS dataset has no mountpoint The appliance reports the dataset with no mountpoint, so it cannot be shared or mounted. Check the dataset on the appliance; a mountpoint may need to be set explicitly.
`DX-9208`	system failure	volume	1	TrueNAS state disagreed with its own report The appliance reported an action as done, but a read-back immediately after disagrees (dataset missing after create, or still there after delete). Check the dataset on the appliance directly; nothing here was rolled back.
`DX-9301`	system failure	network	1	a network system call failed A host tool this engine shells out to for networking (ip, nft, wg, bridge, a CNI plugin, newuidmap/newgidmap, or a raw syscall) could not be run or exited badly. The message names the operation and carries the tool's own error. Read the operation and error in the message; check the tool is installed and the host's network state is sane.
`DX-9302`	system failure	network	1	could not build the OPNsense API client The local HTTP/TLS stack could not be built from the given Target (a malformed CA certificate, most likely). Check `ca_cert_pem`/`insecure_tls` on the Target; nothing on the appliance was reached.
`DX-9304`	system failure	network	1	OPNsense answered with an unexpected status A non-2xx HTTP status this client has no dedicated class for. The message carries the status and body. Read the status/body in the message; it may be a version this client has not been measured against (ADR-0051).
`DX-9307`	system failure	network	1	OPNsense response too large A body past the size this client reads into memory (16 MiB) — the appliance, or whatever answered in its name, is not one of the small JSON bodies this API normally returns. This should not happen against a real OPNsense; check nothing else is answering on that address.
`DX-9308`	system failure	network	1	OPNsense response did not parse The appliance's response body did not parse as the JSON this call expected. Read the raw body in the message; the appliance's API may have changed shape in a newer/older release than ADR-0051's Phase 0 measured (26.1.2).
`DX-9401`	system failure	image	1	registry error An OCI registry answered with an error, or could not be reached. Check the image reference, your login (`delonix image login`) and the network path to the registry.
`DX-9402`	system failure	image	1	a module tree could not be read Reading the module directory failed: a permission, a missing path or an I/O error. Check the path in the message is readable by this user.
`DX-9403`	system failure	image	1	content digest mismatch What the registry served does not hash to the digest that was pinned or declared. The content was refused. Do not work around it: the registry, a mirror or the network may be tampering. Pull again from a trusted source.
`DX-9404`	system failure	image	1	overlay mount failed Mounting the image's overlay root filesystem failed. Read the errno in the message; rootless overlay needs a kernel with unprivileged overlayfs (`delonix system info`).
`DX-9501`	system failure	vm	1	VM tool failed An external tool this VM's lifecycle depends on (virsh, qemu-img, the cloud-hypervisor process) could not be run or exited badly. Read the tool's own error in the message.
`DX-9502`	system failure	vm	1	Cloud Hypervisor API failed The running VM's Cloud Hypervisor VMM could not be reached over its local api-socket, or answered with a non-2xx status. Check the VM is still alive (`delonix vm status`); a vmm that crashed needs `delonix vm start`.
`DX-9503`	system failure	vm	1	VM disk corrupted after stop qemu-img check found a stopped Cloud Hypervisor VM's disk corrupted (BUG-VM-001) — a post-stop check, not the stop itself failing. Run `qemu-img check -r all` on the disk the message names; consider --backend libvirt for VMs that need reliable disk snapshots.
`DX-9504`	system failure	vm	1	snapshot needs a stopped VM The Cloud Hypervisor backend cannot snapshot/restore/delete-snapshot a running VM's disk: the vmm holds it exclusively. Stop the VM first (`delonix vm stop`), or use --backend libvirt for live checkpoints.
`DX-9505`	system failure	vm	1	no libvirt domain description on disk A stopped VM has no <name>.xml recorded, so there is nothing to redefine for a snapshot/restore verb. Start the VM once (`delonix vm start <name>`); the description is written then and stays from then on.
`DX-9506`	system failure	vm	1	VM admission refused The host-protection check refused to boot a VM whose requested memory does not fit in what the host has available. Stop other VMs/containers, reduce the memory, or lower DELONIX_VM_RESERVE_MIB (at your own risk).
`DX-9507`	system failure	vm	1	live disk backup failed A step of the live-disk-backup pipeline (list disks, stage the overlay, snapshot, copy, pivot) failed. Read the step's own error in the message; the VM is left running either way.
`DX-9508`	system failure	vm	1	could not run cloud-localds The cloud-localds tool could not be started, for a reason other than being missing. Read the error in the message; check the host's permissions and free space.
`DX-9509`	system failure	vm	1	cloud-localds failed The cloud-localds tool ran and exited with a non-zero status while building the seed ISO. Check the cloud-init user-data/meta-data/network-config it was given are well-formed.
`DX-9510`	system failure	vm	1	Proxmox request failed The HTTP request to the node could not be sent or answered (network, TLS, DNS). Check the target url and that the node is reachable from this host.
`DX-9511`	system failure	vm	1	Proxmox answered with an HTTP error The node's REST API returned a non-2xx status; the message carries its own error body. Read the body in the message — Proxmox puts the actionable detail there.
`DX-9512`	system failure	vm	1	Proxmox answer had the wrong shape The node's response parsed as JSON but did not carry what a specific call needed (a VM id, a task id). Check the node's Proxmox VE version matches what this build expects.
`DX-9513`	system failure	vm	1	Proxmox task failed A task on the node (create, start, snapshot, destroy) finished with a verdict other than OK; the message carries the node's own reason. Read the node's reason in the message, or check its task log.
`DX-9514`	system failure	vm	1	could not read the Proxmox response The node's answer was not the JSON this client expected. Check the node's Proxmox VE version matches what this build expects; the message carries the start of the body.
`DX-9515`	system failure	vm	1	Proxmox refused the credential The node answered HTTP 401: the API token is wrong or revoked, or the ticket could not be renewed. Check the token id and secret (or the account), and that the token is not expired on the node.
`DX-9516`	system failure	vm	1	Proxmox denied the operation The node answered HTTP 403: the credential is valid but lacks the privilege this route needs (the message names the route). Grant the role the route needs to the token or account on the node — least privilege, one role per use.
`DX-9517`	system failure	vm	1	Proxmox response exceeded the size bound The node's answer was larger than this client is willing to read into memory. Check what the node is serving on that route; an answer this large is not one the engine expects.
`DX-9525`	system failure	vm	1	discarding a failed SDN change failed too A change inside an SDN transaction failed, and the rollback that should have discarded what it had staged (`POST /cluster/sdn/rollback`) failed as well: pending changes, and possibly the SDN lock, are left on the cluster. The message names both failures and the lock token. Roll back by hand with the token the message names (`POST /cluster/sdn/rollback` with `lock-token` and `release-lock=1`), then retry the change.
`DX-9901`	system failure	host	1	a container-runtime system call failed A kernel operation this crate performs to build or manage a container (clone, mount, setns, a cgroup or /proc write) failed. The message carries the operation and the errno. Read the errno in the message; `delonix system info` checks the host requirements (user namespaces, cgroup delegation).

Códigos retirados

Um número nunca muda de significado nem é reutilizado. Quando uma falha passa a ter outro número, o antigo fica aqui com o seu texto e o código que o substituiu, e delonix explain continua a responder-lhe. A D5 do ADR-0059 juntou as falhas dos providers de rede no bloco de reasons DX-C380…DX-C399.

Retired codes

A number never changes meaning and is never reused. When a failure gets another number, the old one stays here with its text and the code that replaced it, and delonix explain still answers it. ADR-0059 D5 folded the network provider failures into the reason block DX-C380…DX-C399.

Código	Substituído por	Última release	Mensagem e significado
`DX-1329`	`DX-1361`	v5.1.1	VIP fora do espaço de endereços de ingress Um VIP de load-balancer está fora do espaço de endereços de ingress (10.200-254.x).
`DX-1330`	`DX-1361`	v5.1.1	especificação de load-balancer inválida Uma lista de backends de `lbset` tem um peso inválido, um backend sem porta, um backend inválido, ou está vazia.
`DX-1342`	`DX-6381`	v4.5.0	não suportado por este provedor de gateway A operação de alias, regra ou commit pedida não está implementada por este GatewayProvider (ADR-0051) — o provider nativo só responde a id()/available().
`DX-1343`	`DX-1380`	v4.5.0	o OPNsense rejeitou os campos enviados A appliance respondeu HTTP 200 com `{"result":"failed","validations":{...}}` — um erro de validação por campo, não uma falha de transporte (ADR-0051 Fase 0, medido ao vivo).
`DX-1345`	`DX-1380`	v4.5.0	nenhum provider de zona de rede configurado Foi aplicado um `kind: NetworkZone`, não há providers.yaml em vigor e o runtime não tem nenhum SegmentProvider registado — o Kind não nomeia provider nenhum, de propósito, para que decida a configuração do próprio runtime.
`DX-1346`	`DX-1380`	v4.5.0	provider de zona de rede ambíguo Está registado mais de um SegmentProvider, não há providers.yaml em vigor, e o `kind: NetworkZone` não tem campo para escolher um pelo nome.
`DX-1347`	`DX-1380`	—	nenhum provider responde a este papel de rede Nada nomeia um provider para o papel: há um providers.yaml em vigor sem networkDefaults.<papel>, ou um NetworkGateway não nomeia provider e estão registados zero ou vários providers de gateway (ADR-0059 D3).
`DX-1348`	`DX-6381`	—	o provider de rede nomeado não está registado Um documento nomeia um provider que não está registado para o seu papel (ADR-0059 D3).
`DX-1551`	`DX-1552`	v5.0.0	regra de firewall de vnet do Proxmox inválida A firewall de uma vnet filtra o tráfego ENCAMINHADO através da vnet e só aceita regras 'forward' — o nó recusa 'in' e 'out' ali — com uma acção ACCEPT, DROP ou REJECT (o nome de um security group não é aceite por este cliente).
`DX-5340`	`DX-5389`	v4.5.0	objecto remoto que não pertence a este motor Já existe no provider remoto — um appliance OPNsense, a SDN de um cluster Proxmox — um objecto com o nome (ou a descrição de regra) que se pediu para garantir ou remover, sem a marca de posse deste motor. É de outra pessoa: este motor recusa adoptá-lo pelo nome, e nunca o apaga.
`DX-5341`	`DX-5389`	v4.5.0	objecto remoto divergiu do declarado Um objecto que este motor criou no provider remoto foi editado lá e já não corresponde ao manifesto. Este motor não tem actualização no lugar para esse provider, por isso o objecto nem é sobrescrito nem é dado como presente.
`DX-5342`	`DX-5389`	v4.5.0	o provider remoto tem alterações preparadas que não são deste motor O provider remoto aplica de uma vez tudo o que está preparado (`filter/apply` e `alias/reconfigure` do OPNsense, `PUT /cluster/sdn` do Proxmox). Há outras alterações preparadas à espera, por isso aplicar agora empurraria o trabalho a meio de outra pessoa junto com o deste motor.
`DX-6303`	`DX-6381`	—	o default de rede nomeia um provider que não está registado O networkDefaults.<papel> do providers.yaml nomeia um provider que não está registado para esse papel. Um default nunca é saltado para se tentar outro provider (ADR-0059 D3).
`DX-6304`	`DX-6381`	—	o provider que criou este recurso não está registado O registo do recurso nomeia o provider que o serviu, e esse provider não está registado agora. Um recurso registado nunca muda de provider quando um default muda (ADR-0059 D3).
`DX-9303`	`DX-6383`	v4.5.0	o pedido ao OPNsense não pôde ser enviado nem respondido Uma falha ao nível de transporte (DNS, TCP, TLS) a falar com a API REST da appliance — não é um estado que a própria appliance tenha devolvido.
`DX-9305`	`DX-7385`	v4.5.0	o OPNsense recusou a credencial HTTP 401 (um par key/secret errado) ou HTTP 302 (nenhum cabeçalho Authorization enviado, redireccionado para o login da GUI) — os dois medidos ao vivo contra uma appliance real (ADR-0051 Fase 0).
`DX-9306`	`DX-7385`	v4.5.0	o OPNsense recusou a operação HTTP 403: uma key/secret válida sem o privilégio que esta rota exige.

Code	Replaced by	Last release	Message and meaning
`DX-1329`	`DX-1361`	v5.1.1	VIP outside the ingress address space A load-balancer VIP is outside the ingress address space (10.200-254.x).
`DX-1330`	`DX-1361`	v5.1.1	invalid load-balancer spec An `lbset` backend list has a bad weight, a backend with no port, an invalid backend, or is empty.
`DX-1342`	`DX-6381`	v4.5.0	not supported by this gateway provider The alias, rule or commit operation asked for is not implemented by this GatewayProvider (ADR-0051) — the native provider answers only id()/available().
`DX-1343`	`DX-1380`	v4.5.0	OPNsense rejected the fields sent The appliance answered HTTP 200 with `{"result":"failed","validations":{...}}` — a per-field validation error, not a transport failure (ADR-0051 Phase 0, measured live).
`DX-1345`	`DX-1380`	v4.5.0	no network zone provider configured `kind: NetworkZone` was applied, no providers.yaml is in force, and the runtime has no SegmentProvider registered — the Kind names no provider itself, on purpose, so the runtime's own configuration decides.
`DX-1346`	`DX-1380`	v4.5.0	ambiguous network zone provider More than one SegmentProvider is registered, no providers.yaml is in force, and `kind: NetworkZone` has no field to pick one by name.
`DX-1347`	`DX-1380`	—	no provider answers this network role Nothing names a provider for the role: a providers.yaml is in force without networkDefaults.<role>, or a NetworkGateway names no provider while zero or several gateway providers are registered (ADR-0059 D3).
`DX-1348`	`DX-6381`	—	the named network provider is not registered A document names a provider that is not registered for its role (ADR-0059 D3).
`DX-1551`	`DX-1552`	v5.0.0	invalid Proxmox vnet firewall rule A vnet's firewall filters traffic FORWARDED through the vnet and takes only 'forward' rules — the node refuses 'in' and 'out' there — with an action of ACCEPT, DROP or REJECT (a security group's name is not accepted by this client).
`DX-5340`	`DX-5389`	v4.5.0	remote object not owned by this engine An object with the name (or rule description) being ensured or removed already exists on the remote provider — an OPNsense appliance, a Proxmox cluster's SDN — without this engine's owner mark. It belongs to someone else, and this engine refuses to adopt it by name, and never deletes it.
`DX-5341`	`DX-5389`	v4.5.0	remote object drifted from the declaration An object this engine created on the remote provider was edited there, and no longer matches the manifest. The provider has no update in place in this engine, so the object is neither overwritten nor reported as present.
`DX-5342`	`DX-5389`	v4.5.0	remote provider has staged changes that are not this engine's The remote provider applies everything that is staged at once (OPNsense `filter/apply` and `alias/reconfigure`, Proxmox `PUT /cluster/sdn`). Other staged changes are waiting there, so committing now would push someone else's half-finished work along with this engine's.
`DX-6303`	`DX-6381`	—	the network default names a provider that is not registered networkDefaults.<role> in providers.yaml names a provider that is not registered for that role. A default is never skipped to try another provider (ADR-0059 D3).
`DX-6304`	`DX-6381`	—	the provider that created this resource is not registered The resource's record names the provider that served it, and that provider is not registered now. A recorded resource never moves to another provider when a default changes (ADR-0059 D3).
`DX-9303`	`DX-6383`	v4.5.0	the request to OPNsense could not be sent or answered A transport-level failure (DNS, TCP, TLS) talking to the appliance's REST API — not a status the appliance itself returned.
`DX-9305`	`DX-7385`	v4.5.0	OPNsense refused the credential HTTP 401 (a wrong key/secret pair) or HTTP 302 (no Authorization header sent at all, redirected toward the GUI login) — both measured live against a real appliance (ADR-0051 Phase 0).
`DX-9306`	`DX-7385`	v4.5.0	OPNsense refused the operation HTTP 403: a valid key/secret without the privilege this route needs.