시리얼 콘솔

이 배포의 CE 한 노드에서 2026-07-28에 캡처했습니다. sitecli/capture-manifest.json에 어느 노드였는지 기록되어 있으며, scripts/capture-sitecli.sh --check로 실제 CE와 명령 표면을 다시 검증할 수 있습니다.

Azure 시리얼 콘솔은 Azure 플랫폼을 통해 노드의 에뮬레이트된 시리얼 포트에 연결됩니다. F5 Distributed Cloud 컨트롤 플레인, 노드의 데이터 플레인, 또는 노드가 제어하는 어떠한 네트워크 경로도 거치지 않습니다 — 바로 그렇기 때문에 다른 모든 방법이 통하지 않을 때 작동합니다.

CE가 애초에 올라오지 않았을 때 이 방법을 사용하십시오: 등록이 실패했거나, 사이트가 테넌트에 존재하지 않거나, 노드는 켜져 있지만 외부로 나가는 경로가 없는 경우입니다. 이 모든 경우에 디버그 API는 중계할 터널이 없습니다. SSH는 등록 실패 후에도 살아남지만, 첫 부팅 시에 키가 이미 기록되어 있고 VNet 내부에서 노드의 내부 주소에 도달할 수 있는 경우에만 그렇습니다 — 처음 마주하는 노드에서는 둘 다 사실이 아닙니다.

노드에 조금이라도 동작하는 네트워크 경로가 있다면 이 방법보다 사이트 콘솔을 먼저 시도하십시오: 사이트 콘솔도 등록 실패 후에 살아남고, 키가 필요 없으며, 이미 노드를 보고 있는 사람을 밀어내지도 않습니다. 시리얼 콘솔은 바로 그 네트워크 경로가 고장난 상황에서 남은 수단입니다.

사전 조건: 부팅 진단

Azure는 시리얼 콘솔을 연결하기 전에 VM에서 부팅 진단이 활성화되어 있어야 합니다. 이는 terraform/modules/ce-node에서 활성화됩니다:

boot_diagnostics {}

빈 블록은 Azure 관리형 스토리지를 선택하므로, 소유해야 할 진단 스토리지 계정, 수명 주기 정책, 액세스 키가 없습니다. 노드에서 확인하십시오:

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

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

부팅 진단은 부팅 시점에 시리얼 로그를 캡처합니다. 이미 실행 중인 VM에 대해 이를 켜더라도 이미 지나간 부팅에 대한 로그는 생성되지 않으므로, az vm boot-diagnostics get-boot-log은 다음과 같이 응답합니다:

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

이는 결함이 아니라 예상된 동작입니다. 부팅 로그는 노드가 다음에 재부팅한 후에 존재합니다. 다만 라이브 콘솔 연결은 즉시 작동합니다 — 로그에 의존하지 않습니다.

터미널 없이 가용성 확인하기

연결하려면 대화형 세션이 필요하지만, 연결이 가능한지 여부는 두 번의 API 호출로 알 수 있습니다. 둘 다 상태 점검에 유용합니다.

해당 서비스는 구독에 대해 활성화되어 있어야 합니다 — 관리자가 테넌트 전체에서 비활성화할 수 있습니다:

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

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

그런 다음 특정 노드의 시리얼 포트에 대한 연결을 요청합니다:

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"

wss://로 시작하는 connectionString — 이 배포에서는 eastus.gateway.serialconsole.azure.com — 은 콘솔을 지금 바로 연결할 수 있음을 의미합니다. 부팅 진단이 활성화되기 전에는 이 호출이 연결할 대상이 없었습니다.

연결하기

확장을 한 번 설치합니다:
Terminal window
```
az extension add --name serial-console
```

연결합니다:

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

셸이 아니라 어플라이언스의 감사 배너 뒤에 있는 노드 자체의 로그인 프롬프트에 도달합니다. 시리얼 콘솔은 채널이 작동함을 증명하는 것이며, 인증을 우회하지는 않습니다.

이 배포에서 시리얼 콘솔을 통한 로그인을 완료한 사람이 없으므로, 이 페이지는 무엇을 입력해야 하는지 말하지 않습니다. admin은 셸이 Site CLI인 어플라이언스 계정이며, 동일한 계정이 비밀번호로 사이트 콘솔을 통해 인증합니다 — 그러나 시리얼 콘솔 로그인에서 비밀번호가 작동한다는 것은 확인되지 않았고, sshd는 admin에 대해 키 전용이므로 두 경로가 동일한 자격 증명 경로가 아님은 명백합니다.

f5-xc-ce-vm-01에서 캡처했으며, systemd 유닛 출력이 별 의미가 없는 중간 부분은 생략했습니다:

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

이 기록에서 주목할 만한 네 가지가 있는데, 디버그 API로는 답할 수 없는 질문에 답해 주기 때문입니다:

cloud-init 완료 — Datasource DataSourceAzure, 22.37초에 완료. 등록이 전혀 되지 않는 노드는 보통 여기서 실패하며, 그것을 볼 수 있는 곳이 바로 이곳입니다.
두 컨테이너 런타임이 모두 시작됨. Container Runtime Interface for OCI (CRI-O)와 Docker Application Container Engine이 각각 [ OK ]이며, 이는 crictl과 docker에서 사람들을 놀라게 하는 이중 런타임 동작에 대한 부팅 시점의 증거입니다.
VP Manager image load와 Argo Watch service — vpm과 Argo가 올라오는 중입니다.
프롬프트는 노드 자체의 것이며, 감사 배너 뒤에 있습니다. 시리얼 콘솔은 로그인 프롬프트를 제공하며, 세션을 제공하지는 않습니다.

az serial-console connect는 터미널을 raw 모드로 전환하므로, 파이프라인이나 TTY가 없는 어떤 환경에서도 실행할 수 없습니다. Azure에 접속하기 전, 클라이언트 측에서 실패합니다:

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

이 트레이스백은 터미널 처리 문제이며, 시리얼 콘솔 장애가 아닙니다.

그러나 연결 자체는 자동화가 가능합니다 — CLI 대신 웹소켓을 직접 제어하십시오. 위의 기록은 TTY 없이 그런 방식으로 캡처한 것입니다. scripts/serial_console_capture.py를 참고하십시오. 사람이 터미널에 앉아 있지 않고도 등록에 실패한 노드에서 부팅 증거를 수집하는 방법입니다.

게이트웨이의 첫 프레임은 출력이 아니라 챌린지이며, 클라이언트는 베어러 토큰으로 응답합니다. 이를 올바르게 수행했더라도 소켓이 즉시 닫히는 경우가 많습니다:

[close] code=1011 reason=Connection not trusted

관찰된 동작: 간헐적으로 성공하며, 지속적으로 사용하면 리소스 그룹의 모든 노드가 거부합니다 — 몇 분 전에 작동했던 노드까지 포함해서입니다. scripts/serial_console_capture.py는 재시도가 종종 성공하기 때문에 기본적으로 재시도합니다.

원인은 규명되지 않았습니다. 각각이 시간을 낭비하게 만드는 그럴듯한 추측이므로, 배제된 것들을 정리합니다:

이것이 아님	확인 방법
ARM/컴퓨트 스로틀링	그 경우 ARM 호출에 HTTP `429`를 반환합니다. 이것은 별도의 데이터 채널에서 발생하는 웹소켓 종료입니다.
프록시에 의한 TLS 가로채기	`openssl s_client -connect <region>.gateway.serialconsole.azure.com:443 \| openssl x509 -noout -issuer`. 진짜 `O=Microsoft Corporation` 발급자라면 이 가능성은 배제되며, 프록시 벤더가 발급자라면 확정입니다. 해결책은 `*.serialconsole.azure.com`을 허용 목록에 추가하는 것입니다.
부팅 진단 비활성화	`az vm show -g <rg> -n <vm> --query diagnosticsProfile`이 `enabled: true`를 보고하는지 확인.
그랜트와 챌린지 사이의 토큰 불일치	둘에 동일한 토큰을 사용하는 것이 올바른 방식이지만, 연결 종료를 막지는 못합니다.

문서화된 Azure 동작은 다음과 같습니다: VM당 시리얼 콘솔 세션은 하나이며, 두 번째 요청이 성공하면 첫 번째를 밀어냅니다. 밀려난 사용자는 연결이 끊기지만 로그아웃되지는 않으므로, 셸 세션은 유지됩니다. 한 노드를 두 사람이 디버깅하면 서로를 반복적으로 밀어냅니다.

대량 작업에는 디버그 API나 SSH를 사용하십시오. 둘 다 이러한 제한이 없습니다. 특히 SSH는 붙여넣기 제한이나 단일 세션 제약이 없으므로, VNet 내부에서 노드에 도달할 수 있다면 언제나 더 나은 선택입니다.

API로는 볼 수 없고 여기서만 볼 수 있는 것

cloud-init이 실행되는 모습, 실패하는 모습, 또는 아예 시작되지 않는 모습 — 등록이 전혀 되지 않는 노드의 일반적인 원인입니다.
register.ves.volterra.io에 대한 등록 시도, 구성 오류나 테넌트가 거부한 토큰까지 포함합니다.
어떤 에이전트도 실행되기 전의 커널 및 부팅 메시지.
동작하는 네트워크 경로가 없을 때의 노드 — 다른 모든 경로를 무력화하는 상황입니다.

ONLINE 상태인 노드에 대해서는 디버그 API를 선호하십시오: 스크립트로 자동화할 수 있고, 다시 실행할 수 있는 증거를 만들며, 하나뿐인 시리얼 포트를 점유하지 않습니다.