Différences

Ci-dessous, les différences entre deux révisions de la page.

--- benevoles:technique:ganeti [2021/10/11 16:17] – ↷ Page déplacée de atrier:technique:ganeti à benevoles:technique:ganeti ljf
+++ benevoles:technique:ganeti [2022/02/06 22:13] (Version actuelle) – [Error while assembling disk: drbd : can't attach local disk] ljf
@@ Ligne 87: / Ligne 87: @@
   * On indique à vgscan (qui est exécuté au boot, entre autres) de ne pas chercher de VG sur les DRBD.
-  sudo sed -i -e 's@#\? \?filter = \[ "a\/\.\*\/" \]@filter = ["r|/dev/cdrom|", "r|/dev/drbd[0-9]+|" ]@' /etc/lvm/lvm.conf
+  sudo sed -i -e 's@#\? \?filter = \[ "a\/\.\*\/" \]@filter = ["r|/dev/cdrom|", "r|/dev/drbd[0-9]+|", "r|/dev/vg_vpsstockage/.*|" ]@' /etc/lvm/lvm.conf
 Le fichier change avec Debian Stretch donc la commande devient :
-  sudo sed -i -e 's@#\? \?filter = \[ "a|\.\*\/|" \]@filter = ["r|/dev/cdrom|", "r|/dev/drbd[0-9]+|" ]@' /etc/lvm/lvm.conf
+  sudo sed -i -e 's@#\? \?filter = \[ "a|\.\*\/|" \]@filter = ["r|/dev/cdrom|", "r|/dev/drbd[0-9]+|" , "r|/dev/vg_vpsstockage/.*|"]@' /etc/lvm/lvm.conf
@@ Ligne 210: / Ligne 210: @@
 Ces hooks, [[http://gitlab.netlib.re/arn/arn-confs/tree/master/ganeti/instance-debootstrap-hooks|récupérables sur notre git]], sont exécutés à la fin du debootstrap.
-  * **aptsources** : copier, dans le rootfs de la VM, un fichier template de sources.list apt situé dans l'arborescence de l'hyperviseur (voir $APTSOURCES_DIR dans le [[atrier:technique:ganeti#variables_de_scripts|fichier de variables globales]].
+  * **aptsources** : copier, dans le rootfs de la VM, un fichier template de sources.list apt situé dans l'arborescence de l'hyperviseur (voir $APTSOURCES_DIR dans le [[benevoles:technique:ganeti#variables_de_scripts|fichier de variables globales]].
   * **grub** : prépare l'installation de GRUB sur la VM. Il ajoute d'une ligne dans rc.local qui installe GRUB puis halt la VM lors du premier boot de celle-ci. Ce script prépare aussi les réponses pour les questions posées par GRUB lors de son installation (genre « où dois-je m'installer ? ») et télécharge le paquet dans l'arborescence de la VM sans l'installer.
@@ Ligne 311: / Ligne 311: @@
 **Exécuté par** : l'hyperviseur sur lequel une VM va booter.
-**Nécessite** : l'ajout des lignes suivantes dans /etc/iproute2/rt_protos ([[atrier:technique:routage#est-ce_que_vous_utilisez_des_tables_de_routage_multiples_pour_ranger_les_differents_services_vpn_vps_housing|signification]]) :
+**Nécessite** : l'ajout des lignes suivantes dans /etc/iproute2/rt_protos ([[benevoles:technique:routage#est-ce_que_vous_utilisez_des_tables_de_routage_multiples_pour_ranger_les_differents_services_vpn_vps_housing|signification]]) :
   #  Used by ARN team
@@ Ligne 325: / Ligne 325: @@
   * On ajoute les routes IPv4 et IPv6 de la VM
-    * « $MYV4 » et « $MYV6 » sont les adresses globales avec lesquelles nos routeurs causent à une VM. Voir [[atrier:technique:routage#selection_de_l_ip_source|routage]].
+    * « $MYV4 » et « $MYV6 » sont les adresses globales avec lesquelles nos routeurs causent à une VM. Voir [[benevoles:technique:routage#selection_de_l_ip_source|routage]].
-    * Pour la signification de « proto Ganeti », voir [[atrier:technique:routage#est-ce_que_vous_utilisez_des_tables_de_routage_multiples_pour_ranger_les_differents_services_vpn_vps_housing|routage]].
+    * Pour la signification de « proto Ganeti », voir [[benevoles:technique:routage#est-ce_que_vous_utilisez_des_tables_de_routage_multiples_pour_ranger_les_differents_services_vpn_vps_housing|routage]].
     * Par défaut, les IPs (v4 et v6) sont routées directement sur la VM, sans next-hop. Cela signifie que nos hyperviseurs envoient directement des demandes ARP/NDP sur la tap et que la VM doit y répondre avant de recevoir du trafic. Ce fonctionnement simpliste ne permet pas (sans bidouille type ARP/NDP proxy) le subnetting IPv6 ou l'utilisation de la VM comme un endpoint VPN, par exemple, car alors, la VM ne sera pas en mesure de répondre aux demandes ARP/NDP de nos hyperviseurs. **Pour permettre cela, il est possible d'ajouter « VIA="true" » dans la configuration réseau de la VM côté hyperviseur. L'IPv4 et le bloc IPv6 seront alors routés via l'adresse locale au lien de la VM et les usages sus-cités deviendront possibles**.
@@ Ligne 339: / Ligne 339: @@
 **Exécuté par** : tous les hyperviseurs, avant la live migration d'une VM.
-**Objectif** : voir [[atrier:technique:routage#differences_entre_quagga_et_bird|routage]]. En gros : si l'on route des IPs/subnet via l'IP (link-locale ou non) d'une VM, alors zebra (module de Quagga qui cause avec Linux) conserve cette route même lorsque l'interface est détruite puisque la VM est migrée.
+**Objectif** : voir [[benevoles:technique:routage#differences_entre_quagga_et_bird|routage]]. En gros : si l'on route des IPs/subnet via l'IP (link-locale ou non) d'une VM, alors zebra (module de Quagga qui cause avec Linux) conserve cette route même lorsque l'interface est détruite puisque la VM est migrée.
@@ Ligne 597: / Ligne 597: @@
   * On ne veut pas un même /64 IPv6 pour toutes nos VMs mais un /56 par VM
   * On n'a pas besoin d'une assignation dynamique des IPs
-  * Notre routage est un peu complexe, voir [[atrier:technique:routage|routage]]
+  * Notre routage est un peu complexe, voir [[benevoles:technique:routage|routage]]
@@ Ligne 1019: / Ligne 1019: @@
 gnt-node list-storage
 </code>
+==== Error while assembling disk: drbd : can't attach local disk ====
+Il peut y avoir des problèmes de conflits entre LVM et drbd.
+Si un hôte à installer des LVM, ces derniers peuvent être détecté par l'hôte. Ceci peut empécher le boot de la VM avec des messages de ce types:
+<code>
+Error while assembling disk: drbdXX : can't attach local disk
+</code>
+On constate alors que ces drbd seront marqué cs:Unconfigured
+<code>
+cat /proc/drbd
+</code>
+De la même façon si ls vg sur le guest s'appelle de la même façon que l'un des vg de l'hôte ceci peut empécher de créer de nouvelles VM.
+La solution à chaud consiste à désactiver les vg sur les noeuds du cluster:
+<code>
+vgdisplay
+vgchange --activate n /dev/vg-113
+</code>
+Attention de ne pas désactiver les vg de l'hôte.
+Dés lors il est en général possible de relancer un start de la VM (ou une création):
+<code>
+gnt-instance start VMNAME
+</code>
+Pour que le redémarrage ce passe bien, il faut a priori filtrer correctement les VG dans /etc/lvm/lvm.conf (propriété filter).
 ===== Docs intéressantes ======