Console série

Capturé le 2026-07-28 depuis un CE de ce déploiement. sitecli/capture-manifest.json consigne le nœud concerné, et scripts/capture-sitecli.sh --check revérifie la surface de commandes face à un CE en fonctionnement.

Azure Serial Console se rattache au port série émulé du nœud via la plateforme Azure. Elle ne traverse ni le plan de contrôle F5 Distributed Cloud, ni le plan de données du nœud, ni aucun chemin réseau contrôlé par le nœud — c’est précisément pourquoi elle fonctionne quand plus rien d’autre ne marche.

Utilisez-la lorsqu’un CE n’a jamais démarré : l’enregistrement a échoué, le site est absent du tenant, ou le nœud est actif mais n’a aucune route sortante. Dans tous ces cas, l’API de débogage n’a aucun tunnel par lequel relayer. SSH survit à un enregistrement échoué, mais uniquement si sa clé a déjà été écrite au premier démarrage et que vous pouvez joindre l’adresse interne du nœud depuis l’intérieur du VNet — ni l’un ni l’autre n’est vrai pour un nœud que vous rencontrez pour la première fois.

Essayez la Site Console avant celle-ci si le nœud dispose de n’importe quel chemin réseau fonctionnel : elle survit également à un enregistrement échoué, ne nécessite aucune clé, et n’expulse pas la personne qui consulte déjà le nœud. La console série est ce qui reste quand le chemin réseau est précisément ce qui est cassé.

Prérequis : diagnostics de démarrage

Azure exige les diagnostics de démarrage sur la VM avant d’accepter d’attacher une console série. Cela est activé par terraform/modules/ce-node :

boot_diagnostics {}

Un bloc vide sélectionne le stockage géré par Azure, il n’y a donc aucun compte de stockage de diagnostics, politique de cycle de vie ou clé d’accès à gérer. Vérifiez-le sur un nœud :

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

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

L'activation n'est pas rétroactive

Les diagnostics de démarrage capturent le journal série au démarrage. Les activer sur une VM déjà en cours d’exécution ne produit pas de journal pour le démarrage déjà survenu, donc az vm boot-diagnostics get-boot-log répond :

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

C’est attendu, pas une défaillance. Un journal de démarrage existera après le prochain redémarrage du nœud. L’attachement de console en direct, en revanche, fonctionne immédiatement — il ne dépend pas du journal.

Vérifier la disponibilité sans terminal

L’attachement nécessite une session interactive, mais savoir s’il pourrait s’attacher tient en deux appels d’API. Les deux sont utiles dans un contrôle de santé.

Le service doit être activé pour l’abonnement — un administrateur peut le désactiver à l’échelle du 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 } }

Puis demandez une connexion au port série d’un nœud précis :

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"

Une connectionString commençant par wss:// — sur ce déploiement eastus.gateway.serialconsole.azure.com — signifie que la console est attachable dès maintenant. Avant l’activation des diagnostics de démarrage, cet appel n’avait rien à quoi s’attacher.

Cette chaîne de connexion est un identifiant

Il s’agit d’un jeton porteur à courte durée de vie intégré dans une URL. Ne le journalisez pas, ne le collez pas dans un ticket, ne le commitez pas. N’affichez que l’hôte lorsque vous démontrez que l’appel a fonctionné.

Attachement

1. Installez l’extension une seule fois :

   az extension add --name serial-console

2. Attachez-vous :

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

3. Vous arrivez sur l’invite de connexion propre au nœud, pas sur un shell, derrière la bannière d’audit de l’appliance. La console série prouve que le canal fonctionne ; elle ne contourne pas l’authentification.

   L'identifiant accepté par la connexion série n'est pas vérifié

   Personne n’a effectué de connexion complète via la console série sur ce déploiement, cette page n’indique donc pas quoi saisir. admin est le compte de l’appliance dont le shell est le Site CLI, et le même compte s’authentifie via la Site Console avec un mot de passe — mais il n’a pas été démontré qu’un mot de passe fonctionne pour la connexion via console série, et sshd est en mode clé uniquement pour admin, donc les deux ne relèvent manifestement pas du même chemin d’authentification.

Capturé depuis f5-xc-ce-vm-01, tronqué au milieu là où la sortie des unités systemd n’apporte rien :

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

Quatre éléments de cette transcription méritent attention, car ils répondent à des questions que l’API de débogage ne peut pas traiter :

• cloud-init a abouti — Datasource DataSourceAzure, terminé à 22,37 secondes. Un nœud qui ne s’enregistre jamais a généralement échoué ici, et c’est là que vous le voyez.
• Les deux runtimes de conteneurs ont démarré. Container Runtime Interface for OCI (CRI-O) et Docker Application Container Engine sont chacun [ OK ], ce qui constitue la preuve au démarrage du comportement à double runtime qui surprend dans crictl et docker.
• VP Manager image load et Argo Watch service — vpm et Argo qui démarrent.
• L’invite est celle du nœud lui-même, derrière sa bannière d’audit. La console série vous donne une invite de connexion, pas une session.

L'attachement interactif nécessite un vrai terminal — mais il peut être scripté

az serial-console connect place le terminal en mode brut, il ne peut donc pas s’exécuter depuis un pipeline ou tout contexte dépourvu de TTY. Il échoue côté client, avant de contacter Azure :

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

Cette trace concerne la gestion du terminal, pas une panne de la console série.

L’attachement lui-même, en revanche, est automatisable — pilotez directement le websocket au lieu de la CLI. La transcription ci-dessus a été capturée de cette manière, sans TTY. Voir scripts/serial_console_capture.py, qui est la façon dont vous collecteriez des preuves de démarrage depuis un nœud n’ayant pas réussi à s’enregistrer, sans humain assis devant un terminal.

Prévoyez de réessayer : la passerelle refuse environ une tentative sur deux

La première trame de la passerelle est un challenge, pas une sortie, et le client y répond avec un jeton porteur. Même lorsque cela est fait correctement, le socket se ferme souvent immédiatement :

[close] code=1011 reason=Connection not trusted

Comportement observé : cela réussit de façon intermittente, et en usage soutenu chaque nœud du groupe de ressources refuse — y compris des nœuds qui fonctionnaient quelques minutes plus tôt. scripts/serial_console_capture.py réessaie par défaut, car réessayer fonctionne souvent.

La cause n’est pas établie. Ce qui a été écarté, car chacune de ces hypothèses est plausible et fait perdre du temps :

Pas ceci	Comment le confirmer
Limitation (throttling) ARM/compute	Cela renvoie un HTTP 429 sur les appels ARM. Ici il s’agit d’une fermeture de websocket sur un canal de données distinct.
Interception TLS par un proxy	openssl s_client -connect <region>.gateway.serialconsole.azure.com:443 | openssl x509 -noout -issuer. Un émetteur authentique O=Microsoft Corporation l’écarte ; un éditeur de proxy comme émetteur le confirme, et le correctif consiste à autoriser *.serialconsole.azure.com.
Diagnostics de démarrage désactivés	az vm show -g <rg> -n <vm> --query diagnosticsProfile rapportant enabled: true.
Décalage de jeton entre l’octroi et le challenge	Utiliser un seul jeton pour les deux est la bonne pratique, mais n’empêche pas la fermeture.

Ce qui est un comportement Azure documenté : une seule session de console série par VM, et une seconde requête réussie expulse la première. L’utilisateur expulsé est déconnecté mais pas déconnecté de sa session, donc la session shell survit. Deux personnes déboguant un même nœud se déplaceront mutuellement de façon répétée.

Pour un travail en masse, préférez l’API de débogage ou SSH, qui n’ont aucune de ces limites. SSH en particulier n’a pas de plafond de collage ni de restriction à une seule session, c’est donc le meilleur choix dès lors que le nœud est joignable depuis l’intérieur du VNet.

Le collage est plafonné à 2 048 caractères

Azure limite la longueur du collage en console série à 2 048 caractères, afin d’éviter de surcharger le port série. Envoyer une commande longue — ou un lot de commandes en une seule écriture — échoue d’une manière qui ressemble à un blocage ou à une limitation plutôt qu’à une limite de longueur.

Envoyez les commandes une par une. C’est une contrainte réelle pour toute collecte en masse via console série, et une raison supplémentaire de préférer l’API de débogage pour ce travail.

Ce que vous pouvez voir ici et que l’API ne peut pas vous montrer

• cloud-init en cours d’exécution, en échec, ou jamais démarré — la cause habituelle d’un nœud qui ne s’enregistre jamais.
• Les tentatives d’enregistrement auprès de register.ves.volterra.io, y compris une erreur de configuration ou un jeton rejeté par le tenant.
• Les messages du noyau et de démarrage antérieurs à l’exécution de tout agent.
• Le nœud lorsqu’il n’a aucun chemin réseau fonctionnel, ce qui met en échec toutes les autres voies.

Pour un nœud qui est ONLINE, préférez l’API de débogage : elle est scriptable, elle produit des preuves que vous pouvez rejouer, et elle n’occupe pas l’unique port série.