Console serial

Capturado em 28/07/2026 de um CE deste deployment. sitecli/capture-manifest.json registra qual nó foi usado, e scripts/capture-sitecli.sh --check reverifica a superfície de comandos contra um CE ativo.

O Azure Serial Console se conecta à porta serial emulada do nó através da plataforma Azure. Ele não passa pelo control plane do F5 Distributed Cloud, pelo data plane do nó, nem por qualquer caminho de rede que o nó controle — que é exatamente o motivo pelo qual funciona quando nada mais funciona.

Recorra a ele quando um CE nunca subiu: o registro falhou, o site está ausente do tenant, ou o nó está ativo mas não tem rota de saída. Em todos esses casos, a API de depuração não tem túnel pelo qual retransmitir. O SSH sobrevive a um registro falho, mas somente se sua chave já tiver sido gravada na primeira inicialização e você conseguir alcançar o endereço interno do nó de dentro da VNet — nada disso é verdade para um nó que você está conhecendo pela primeira vez.

Tente o Site Console antes deste se o nó tiver qualquer caminho de rede funcional: ele também sobrevive a um registro falho, não precisa de chave e não expulsa a pessoa que já está olhando o nó. O console serial é o que resta quando o caminho de rede é justamente o que está quebrado.

Pré-requisito: diagnóstico de inicialização

O Azure exige diagnóstico de inicialização na VM antes de conectar um console serial. Isso é habilitado por terraform/modules/ce-node:

boot_diagnostics {}

Um bloco vazio seleciona o armazenamento gerenciado pelo Azure, portanto não há conta de armazenamento de diagnóstico, política de ciclo de vida ou chave de acesso para gerenciar. Confirme em um nó:

az vm show -g <resource-group> -n <vm-name> --query diagnosticsProfile

{ "bootDiagnostics": { "enabled": true } }

Habilitar não é retroativo

O diagnóstico de inicialização captura o log serial na inicialização. Ativá-lo para uma VM que já está em execução não produz um log da inicialização que já ocorreu, então az vm boot-diagnostics get-boot-log responde:

<Error><Code>BlobNotFound</Code><Message>The specified blob does not exist.

Isso é esperado, não uma falha. Um log de inicialização existe após o próximo reboot do nó. A conexão ao console ao vivo, no entanto, funciona imediatamente — ela não depende do log.

Verificando a disponibilidade sem um terminal

Conectar exige uma sessão interativa, mas saber se a conexão seria possível são duas chamadas de API. Ambas são úteis em uma verificação de saúde.

O serviço precisa estar habilitado para a subscription — um administrador pode desabilitá-lo para todo o tenant:

az rest --method get --url \
  "https://management.azure.com/subscriptions/<sub>/providers/Microsoft.SerialConsole/consoleServices/default?api-version=2018-05-01"

{ "properties": { "disabled": false } }

Depois, solicite uma conexão à porta serial de um nó específico:

az rest --method post \
  --headers "Content-Type=application/json" --body '{}' --url \
  "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>/providers/Microsoft.SerialConsole/serialPorts/0/connect?api-version=2018-05-01"

Um connectionString começando com wss:// — neste deployment, eastus.gateway.serialconsole.azure.com — significa que o console pode ser conectado agora. Antes de o diagnóstico de inicialização ser habilitado, essa chamada não tinha nada a que se conectar.

Essa string de conexão é uma credencial

Ela é um token bearer de curta duração embutido em uma URL. Não a registre em logs, não a cole em um ticket e não a faça commit. Imprima apenas o host quando estiver demonstrando que a chamada funcionou.

Conectando

1. Instale a extensão uma vez:

   az extension add --name serial-console

2. Conecte:

   az serial-console connect -g <resource-group> -n <vm-name>

3. Você chega ao próprio prompt de login do nó, não a um shell, atrás do banner de auditoria do appliance. O console serial prova que o canal funciona; ele não contorna a autenticação.

   Qual credencial o login serial aceita não foi verificado

   Ninguém completou um login pelo console serial neste deployment, portanto esta página não diz o que digitar. admin é a conta do appliance cujo shell é a Site CLI, e a mesma conta se autentica pelo Site Console com uma senha — mas não foi demonstrado que uma senha funciona no login do console serial, e o sshd aceita apenas chaves para admin, então os dois comprovadamente não são o mesmo caminho de credencial.

Capturado de f5-xc-ce-vm-01, com omissão no meio onde a saída da unidade systemd não acrescenta nada:

+-----------------------------------------------+
Connected to the serial port of the VM.
If no login prompt is displayed, press ENTER.
+-----------------------------------------------+


Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
init_cea_offsets KASLR using RDRAND RDTSC...
Poking KASLR using RDRAND RDTSC...

Welcome to Red Hat Enterprise Linux 9.2024.6.3 (Plow) dracut-057-44.git20230822.el9 (Initramfs)!

[  OK  ] Started Dispatch Password …ts to Console Directory Watch.

... [320 lines of systemd unit output elided]

[  OK  ] Started Serial Getty on ttyS0.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started OpenSSH server daemon.
[  OK  ] Started Container Runtime Interface for OCI (CRI-O).
[   19.960784] cloud-init[1311]: Cloud-init v. 23.1.1-12.el9_3 running 'modules:config' at Sun, 26 Jul 2026 13:13:54 +0000. Up 19.84 seconds.
[  OK  ] Finished Apply the settings specified in cloud-config.
         Starting Execute cloud user/final scripts...
[  OK  ] Started Docker Application Container Engine.
         Starting Argo Watch service...
         Starting VP Manager image load...
[  OK  ] Started Argo Watch service.
[   21.544663] cloud-init[1512]: Cloud-init v. 23.1.1-12.el9_3 running 'modules:final' at Sun, 26 Jul 2026 13:13:56 +0000. Up 21.41 seconds.
[   22.751629] cloud-init[1512]: Cloud-init v. 23.1.1-12.el9_3 finished at Sun, 26 Jul 2026 13:13:57 +0000. Datasource DataSourceAzure [seed=/var/lib/waagent].  Up 22.37 seconds
[  OK  ] Finished Execute cloud user/final scripts.
[  OK  ] Started libcontainer conta…f4b59f3b96c31ee10cd95f6eb371c.


UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED
All actions performed on this device are audited
f5-xc-ce-vm-01 login: [  123.107074] Warning: Deprecated Driver is detected: iptables will not be maintained in a future major release and may be disabled
[  123.144641] Warning: Deprecated Driver is detected: ip6tables will not be maintained in a future major release and may be disabled

Quatro coisas nessa transcrição valem atenção, porque respondem perguntas que a API de depuração não pode:

• cloud-init concluído — Datasource DataSourceAzure, finalizado em 22,37 segundos. Um nó que nunca se registra geralmente falhou aqui, e é aqui que você vê isso.
• Ambos os runtimes de container iniciaram. Container Runtime Interface for OCI (CRI-O) e Docker Application Container Engine estão cada um [ OK ], o que é a prova em tempo de inicialização do comportamento de runtime duplo que surpreende as pessoas em crictl e docker.
• VP Manager image load e Argo Watch service — vpm e Argo subindo.
• O prompt é o do próprio nó, atrás do seu banner de auditoria. O console serial te dá um prompt de login, não uma sessão.

Conectar interativamente exige um terminal real — mas pode ser automatizado

az serial-console connect coloca o terminal em modo raw, portanto não pode ser executado a partir de um pipeline ou de qualquer contexto sem um TTY. Ele falha no lado do cliente, antes de contatar o Azure:

ERROR: (19, 'Operation not supported by device')
  File ".../azext_serialconsole/custom.py", line 633, in connect_serialconsole
    GV.serial_console_instance.launch_console()

Esse traceback é tratamento de terminal, não uma indisponibilidade do console serial.

A conexão em si, no entanto, é automatizável — controle o websocket diretamente em vez da CLI. A transcrição acima foi capturada dessa forma, sem TTY. Veja scripts/serial_console_capture.py, que é como você coletaria evidências de inicialização de um nó que falhou ao se registrar sem alguém sentado diante de um terminal.

Espere ter que repetir: o gateway recusa aproximadamente uma tentativa a cada duas

O primeiro frame do gateway é um desafio, não saída, e o cliente o responde com um token bearer. Mesmo quando isso é feito corretamente, o socket frequentemente fecha imediatamente:

[close] code=1011 reason=Connection not trusted

Comportamento observado: funciona de forma intermitente, e sob uso sustentado todos os nós do resource group recusam — incluindo nós que funcionaram minutos antes. scripts/serial_console_capture.py faz novas tentativas por padrão porque repetir frequentemente funciona.

A causa não está estabelecida. O que foi descartado, porque cada item é um palpite plausível que desperdiça tempo:

Não é isso	Como confirmar
Throttling de ARM/compute	Isso retorna HTTP 429 nas chamadas ARM. Aqui é um fechamento de websocket em um canal de dados separado.
Interceptação de TLS por um proxy	openssl s_client -connect <region>.gateway.serialconsole.azure.com:443 | openssl x509 -noout -issuer. Um emissor genuíno O=Microsoft Corporation descarta isso; um fornecedor de proxy como emissor confirma, e a correção é incluir *.serialconsole.azure.com na lista de permissões.
Diagnóstico de inicialização desabilitado	az vm show -g <rg> -n <vm> --query diagnosticsProfile reportando enabled: true.
Divergência de token entre a concessão e o desafio	Usar um único token para ambos é a prática correta, mas não evita o fechamento.

O que é comportamento documentado do Azure: uma sessão de console serial por VM, e uma segunda requisição bem-sucedida expulsa a primeira. O usuário expulso é desconectado, mas não deslogado, então a sessão de shell sobrevive. Duas pessoas depurando um mesmo nó vão deslocar uma à outra repetidamente.

Para trabalho em massa, prefira a API de depuração ou o SSH, nenhum dos quais tem esses limites. O SSH, em particular, não tem limite de colagem nem restrição de sessão única, portanto é a melhor escolha sempre que o nó estiver acessível de dentro da VNet.

A colagem é limitada a 2.048 caracteres

O Azure limita o comprimento da colagem no console serial a 2.048 caracteres, para evitar sobrecarregar a porta serial. Enviar um comando longo — ou um lote de comandos em uma única escrita — falha de uma forma que parece um travamento ou um throttle em vez de um limite de comprimento.

Envie os comandos individualmente. Isso é uma restrição real para qualquer coleta em massa pelo console serial, e outra razão para preferir a API de depuração para esse trabalho.

O que você pode ver aqui e a API não pode mostrar

• cloud-init em execução, falhando ou nunca iniciando — a causa usual de um nó que nunca se registra.
• Tentativas de registro contra register.ves.volterra.io, incluindo um erro de configuração ou um token que o tenant rejeitou.
• Mensagens de kernel e inicialização de antes de qualquer agente estar em execução.
• O nó quando ele não tem nenhum caminho de rede funcional, o que derrota todas as outras rotas.

Para um nó que está ONLINE, prefira a API de depuração: ela é automatizável, produz evidências que você pode reexecutar e não ocupa a única porta serial.