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@_' tail -50 /var/log/dnsmasq-_.log cat /run/dnsmasq-_.leases cat /etc/dnsmasq.d/_.conf **Backend ``two``** .. code-block:: bash systemctl status 'dhcp@_' journalctl -u 'dhcp@_' -n 50 # Ce que le serveur a réellement en mémoire echo '{"verb":"get-state"}' \ | socat - UNIX-CONNECT:/run/two/dhcp/_.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/_.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@' ls -l /run/two/metadata// 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//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.