Diagnostic

Diagnostic#

Symptôme, cause probable, vérification. Les causes listées sont celles réellement rencontrées.

La ressource part en error juste après le 202#

Execute a échoué : la cause est dans le journal de l’agent, pas dans la réponse HTTP.

journalctl -u agent -n 100

Cas fréquents :

  • subnet en mode public_ip — la mise en place host n’est pas implémentée, l’échec est attendu ;

  • vxlan_id déjà utilisé sur l’host ;

  • bridge cible absent : iface_type inconnu retombé sur default_interface, lui-même inexistant.

Avant toute recréation, émettre un DELETE : il n’y a pas de rollback, les objets système partiellement créés subsistent.

La VM démarre mais n’a pas d’adresse#

Le DHCP est servi par une instance dédiée au subnet. Quelle unit selon dhcp.backend :

Backend ``dnsmasq``

systemctl status 'dnsmasq@<netns>_<bridge>'
tail -50 /var/log/dnsmasq-<netns>_<bridge>.log
cat /run/dnsmasq-<netns>_<bridge>.leases
cat /etc/dnsmasq.d/<netns>_<bridge>.conf

Backend ``two``

systemctl status 'dhcp@<netns>_<bridge>'
journalctl -u 'dhcp@<netns>_<bridge>' -n 50

# Ce que le serveur a réellement en mémoire
echo '{"verb":"get-state"}' \
  | socat - UNIX-CONNECT:/run/two/dhcp/<netns>_<bridge>.sock | jq .

# Ce qu'il enverrait à une MAC donnée, sans effet de bord
echo '{"verb":"probe","mac":"00:22:33:00:00:0A"}' \
  | socat - UNIX-CONNECT:/run/two/dhcp/<netns>_<bridge>.sock | jq .lease

probe est le point de départ le plus rapide : il montre l’adresse, le masque, le routeur, les DNS et les routes classless tels qu’ils partiraient. Une réponse "served": false signifie que la MAC n’est pas réservée — l’ordre set-host n’a jamais atteint le serveur, ou la VM n’a pas été créée par cet agent.

Le watchdog signale ces écarts de lui-même, à chaque tick, en comparant l’état servi à la base : dhcp reservation missing on the server, stale dhcp reservation, dhcp reservation diverges. Regarder ses notifications avant de sonder à la main.

Si le serveur ne voit passer aucune requête, le problème est en amont : tap absent, bridge non raccordé, VM dans le mauvais netns.

La VM a une adresse mais cloud-init n’applique rien#

Deux causes distinctes, à écarter dans cet ordre.

1. La VM porte déjà cet ``instance-id``. instance-id vaut le nom de la VM : sur un disque déjà provisionné sous le même nom, cloud-init considère l’instance connue et ne rejoue pas le user-data. Vérification dans le guest :

cloud-init query instance-id
ls /var/lib/cloud/instances/

2. Le serveur de metadata est injoignable. Depuis le guest :

ip route
curl -s http://169.254.169.254/latest/meta-data/

La route 169.254.169.254/32 doit être présente, avec l”interface_ip du subnet comme next-hop. Si elle est absente ou pointe ailleurs, la DNAT posée en PREROUTING dans le netns n’est jamais traversée : la trame est commutée en L2 et le serveur reste injoignable. Voir Modes réseau.

Depuis l’host, l’instance correspondante :

systemctl status 'metadata@<vm>'
ls -l /run/two/metadata/<vm>/

Le user-data est servi vide#

Un document fourni explicitement vide est servi vide — ce n’est pas la même chose qu’un document absent, qui retombe sur le template. Vérifier le contenu réellement écrit :

cat /run/two/metadata/<vm>/user-data

Un base64 invalide, lui, aurait été rejeté en 400 à la création.

La VM ne démarre pas (UEFI)#

uefi: true exige les fichiers OVMF déclarés dans la configuration :

ls -l /usr/share/OVMF/OVMF_CODE.fd /usr/share/OVMF/OVMF_VARS.fd
ls -l /run/two/vms/efi/

Sur Debian et Ubuntu, le paquet est ovmf.

Le DELETE renvoie 409#

La suppression n’est autorisée que depuis running ou error. Depuis creating ou deleting, attendre l’état stable. Pour un VPC, tous les subnets doivent être supprimés d’abord.

La base et le système ont divergé#

Le watchdog signale une ressource running absente du système. Il ne répare rien : la correction est un DELETE explicite suivi d’une recréation. Après un redémarrage de l’agent, les ressources restées transitoires sont basculées en error par la migration de démarrage — elles n’ont pas forcément échoué, elles ont été interrompues.

L’agent ne redémarre pas après un arrêt brutal#

Badger rejoue son journal au démarrage : c’est normal et attendu, notamment si le budget d’arrêt précédent a été dépassé et que la base n’a pas été fermée. Si le démarrage échoue vraiment, le message se trouve dans journalctl -u agent.

Note

Les VM ne sont pas réattachées au redémarrage de l’agent : un processus QEMU survivant à l’agent n’est plus piloté par lui.