two/docs/exploitation/diagnostic.rst

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.

.. code-block:: bash

   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``**

.. code-block:: bash

   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``**

.. code-block:: bash

   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 :

.. code-block:: bash

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

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

.. code-block:: bash

   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
:doc:`/concepts/modes-reseau`.

Depuis l'host, l'instance correspondante :

.. code-block:: bash

   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 :

.. code-block:: bash

   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 :

.. code-block:: bash

   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.