148 lines
5.2 KiB
ReStructuredText
148 lines
5.2 KiB
ReStructuredText
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.
|