add a new libvirt hypervisor #34

Open
opened 2022-10-06 17:21:10 +00:00 by easter-eggs · 11 comments

The internal Easter-eggs ticket is copy/pasted here for transparency purposes. The content is in French because it is the language used by the Easter-eggs sysadmin team.


Followup of https://gitea.gna.org/Hostea/organization/issues/32

* Forum topic https://forum.hostea.org/t/provide-a-libvirt-hypervisor-for-the-fleet/157 * Internal Easter-eggs ticket https://rt.easter-eggs.fr/Ticket/Display.html?id=87971 The internal Easter-eggs ticket is copy/pasted here for transparency purposes. The content is in French because it is the language used by the Easter-eggs sysadmin team. --- Followup of https://gitea.gna.org/Hostea/organization/issues/32
easter-eggs added the
Expense
Improve Gna!
labels 2022-10-06 17:21:10 +00:00
easter-eggs self-assigned this 2022-10-06 17:21:10 +00:00

La prochaine étape de ce ticket consiste à attribuer un pool d'IPs publiques à l'hyperviseur pec-hyp-01.

Proposition :

Les IPs sont dans le réseau 37.9.142.0/24 associé à un vlan 901
Attribution des IPs:
pec-hyp-01: 37.9.142.2
VIP sur les fw-pa2-* : fw-pa2-v901 : 37.9.142.1
VMS : 37.9.142.3 -> 37.9.142.254

Pour ce faire :

  1. Déclarer le réseau 37.9.142.0/24 associé au vlan 901 dans racktables

  2. Sur fw-pa2-01 et fw-pa2-02, ajouter une interface bond1.901 dans /etc/network/interfaces :

    auto bond1.901
    iface bond1.901 inet manual
    post-up ifconfig bond1.901 up
    pre-down ifconfig bond1.901 down

  3. Sur fw-pa2-vip, ajouter une VIP pacemaker :

crm configure primitive p_vip_901 ocf💓IPaddr2
params ip="37.9.142.1" cidr_netmask="24" broadcast="37.9.142.255" nic="bond1.901"
meta migration-threshold="2"
op start interval="0" timeout="60s"
op stop interval="0" timeout="60s"
op monitor interval="15s" timeout="60s"

  1. Ajouter les règles parefeu autorisant le réseau sur les fw-pa2. A minima :

-A FORWARD -d 37.9.142.0/24 -o bond1.901 -m state --state NEW -j ACCEPT
-A OUTPUT -d 37.9.142.0/24 -o bond1.901 -m state --state NEW -j ACCEPT

  1. Sur pec-hyp-01, configurer une interface avec l'IP 37.9.142.2. Ajouter en route par défaut 37.9.142.1

  2. Sur sw-pa2-*, configurer le vlan 901 à la place du vlan 504 :

les ports 21, 22 et 34 doivent autoriser en trunk le Vlan 901.

  1. Configurer les tables de routage sur les cr-pa2 (+ ospf)

  2. Sur pec-hyp-01, Configurer le réseau pour les VMs : ajouter un bridge

@Arnaud, @Manu, est-ce que vous voyez d'autres choses à faire ?

La prochaine étape de ce ticket consiste à attribuer un pool d'IPs publiques à l'hyperviseur pec-hyp-01. Proposition : Les IPs sont dans le réseau 37.9.142.0/24 associé à un vlan 901 Attribution des IPs: pec-hyp-01: 37.9.142.2 VIP sur les fw-pa2-* : fw-pa2-v901 : 37.9.142.1 VMS : 37.9.142.3 -> 37.9.142.254 Pour ce faire : 1. Déclarer le réseau 37.9.142.0/24 associé au vlan 901 dans racktables 2. Sur fw-pa2-01 et fw-pa2-02, ajouter une interface bond1.901 dans /etc/network/interfaces : auto bond1.901 iface bond1.901 inet manual post-up ifconfig bond1.901 up pre-down ifconfig bond1.901 down 3. Sur fw-pa2-vip, ajouter une VIP pacemaker : crm configure primitive p_vip_901 ocf:heartbeat:IPaddr2 \ params ip="37.9.142.1" cidr_netmask="24" broadcast="37.9.142.255" nic="bond1.901" \ meta migration-threshold="2" \ op start interval="0" timeout="60s" \ op stop interval="0" timeout="60s" \ op monitor interval="15s" timeout="60s" 4. Ajouter les règles parefeu autorisant le réseau sur les fw-pa2. A minima : -A FORWARD -d 37.9.142.0/24 -o bond1.901 -m state --state NEW -j ACCEPT -A OUTPUT -d 37.9.142.0/24 -o bond1.901 -m state --state NEW -j ACCEPT 5. Sur pec-hyp-01, configurer une interface avec l'IP 37.9.142.2. Ajouter en route par défaut 37.9.142.1 6. Sur sw-pa2-*, configurer le vlan 901 à la place du vlan 504 : les ports 21, 22 et 34 doivent autoriser en trunk le Vlan 901. 7. Configurer les tables de routage sur les cr-pa2 (+ ospf) 8. Sur pec-hyp-01, Configurer le réseau pour les VMs : ajouter un bridge @Arnaud, @Manu, est-ce que vous voyez d'autres choses à faire ?
easter-eggs added spent time 2022-10-06 17:23:41 +00:00
2 hours

Tâches réalisées :

  • Déclaration d'un réseau et d'un vlan sur racktables
  • Configuration d'une interface dédiée au vlan sur les parefeu de pa2.
Tâches réalisées : - Déclaration d'un réseau et d'un vlan sur racktables - Configuration d'une interface dédiée au vlan sur les parefeu de pa2.
easter-eggs added spent time 2022-10-06 17:24:15 +00:00
1 hour 30 minutes

Tâche réalisée :

Ajout d'une vip sur les parefeu de pa2

Tâche réalisée : Ajout d'une vip sur les parefeu de pa2
easter-eggs added spent time 2022-10-06 17:24:50 +00:00
15 minutes

Tâches réalisée :

  • Configuration du vlan et du routage pour l'hyperviseur et sa flotte.
  • Configuration de l'hyperviseur
Tâches réalisée : - Configuration du vlan et du routage pour l'hyperviseur et sa flotte. - Configuration de l'hyperviseur
easter-eggs added spent time 2022-10-06 17:25:13 +00:00
2 hours
dachary added spent time 2022-10-10 21:56:42 +00:00
4 hours
dachary deleted spent time 2022-10-10 21:57:50 +00:00
- 4 hours

Test de déploiement sur l'hyperviseur avec enough (cf https://forum.gna.org/t/provide-a-libvirt-hypervisor-for-the-fleet/157/4 [Ouvrir l'URL])

Test de déploiement sur l'hyperviseur avec enough (cf https://forum.gna.org/t/provide-a-libvirt-hypervisor-for-the-fleet/157/4 [Ouvrir l'URL])
easter-eggs added spent time 2022-10-19 12:52:03 +00:00
3 hours

Mise en place de la supervision, des sauvegardes et de la métrologie (il reste à créer une nouvelle organisation dans grafana)

Mise en place de la supervision, des sauvegardes et de la métrologie (il reste à créer une nouvelle organisation dans grafana)
easter-eggs added spent time 2022-10-19 12:52:33 +00:00
1 hour 45 minutes

Debug du problème de résolution DNS lors de l'utilisation de virt-builder.

La commande problématique est :

'virt-builder' 'debian-11' '--no-cache' '--output' '/var/lib/libvirt/images/enough/l.gna.org/debian-11.qcow2' '--format' 'qcow2' '--size' '6G' '--run-command' 'apt-get --allow-releaseinfo-change update' '--install' 'sudo' '--root-password' 'disabled' '--run-command' 'dpkg-reconfigure --frontend=noninteractive openssh-server' '--run-command' 'useradd -s /bin/bash -m debian || true ; echo "debian ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/90-debian'

2 resolvers were configured on the hypervisor but the access to the first one is not authorized and the second one is not tried when DSN queries are launched from the supermin appliance used by virt-builder. I have left the only resolver that works for the moment.

Debug du problème de résolution DNS lors de l'utilisation de virt-builder. La commande problématique est : 'virt-builder' 'debian-11' '--no-cache' '--output' '/var/lib/libvirt/images/enough/l.gna.org/debian-11.qcow2' '--format' 'qcow2' '--size' '6G' '--run-command' 'apt-get --allow-releaseinfo-change update' '--install' 'sudo' '--root-password' 'disabled' '--run-command' 'dpkg-reconfigure --frontend=noninteractive openssh-server' '--run-command' 'useradd -s /bin/bash -m debian || true ; echo "debian ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/90-debian' 2 resolvers were configured on the hypervisor but the access to the first one is not authorized and the second one is not tried when DSN queries are launched from the supermin appliance used by virt-builder. I have left the only resolver that works for the moment.
easter-eggs added spent time 2022-10-20 10:05:07 +00:00
2 hours

@brenard

pas mal de mails bloqués dans la mailq de ce serveur.

À priori, problème de parefeu et des config sudo a revoir (si ça pas encore été fait). Par ailleurs, je suis intervenu car l'utilisateur local enough n'avait pas d'alias mail : j'en ai mis un en place vers root, donc eeadmin, donc supervision@easter-eggs.com.

J'ai ajouté une règle sur les parefeu pour autoriser l'envoi de mails vers le mx ee.

@brenard pas mal de mails bloqués dans la mailq de ce serveur. À priori, problème de parefeu et des config sudo a revoir (si ça pas encore été fait). Par ailleurs, je suis intervenu car l'utilisateur local enough n'avait pas d'alias mail : j'en ai mis un en place vers root, donc eeadmin, donc supervision@easter-eggs.com. J'ai ajouté une règle sur les parefeu pour autoriser l'envoi de mails vers le mx ee.
easter-eggs added spent time 2022-10-24 15:48:48 +00:00
15 minutes
easter-eggs added spent time 2022-10-24 15:48:55 +00:00
45 minutes
https://forum.gna.org/t/provide-a-libvirt-hypervisor-for-the-fleet/157/13
easter-eggs added spent time 2022-10-25 13:49:48 +00:00
2 hours

https://forum.gna.org/t/provide-a-libvirt-hypervisor-for-the-fleet/157/14 [Ouvrir l'URL]

And now it obtains an IP from the expected range 🎉 one step forward.

[ 4.9] Installing firstboot command: env PORT=22 ROUTED=enp1s0 NOT_ROUTED=enp2s0 UNCONFIGURED=noname bash -x /root/network.sh
try-host: creating host

Starting install...
Domain creation completed.
try-host: waiting for ipv4 to be allocated
Libvirt.get_ipv4: interfaceAddresses returned {}, Retrying in 1 seconds...
Libvirt.get_ipv4: interfaceAddresses returned {}, Retrying in 2 seconds...
Libvirt.get_ipv4: interfaceAddresses returned {}, Retrying in 4 seconds...
Libvirt.get_ipv4: interfaceAddresses returned {}, Retrying in 8 seconds...
try-host: waiting for 37.9.143.6:22 to come up
Check if SSH is available on 37.9.143.6:22
SSH.wait_for_ssh: [Errno 113] No route to host, Retrying in 1 seconds...

The firewall is probably blocking some more and preventing communication with port 22.

En fait c'était un problème au niveau de la configuration du virtual network enough-ext. L'IP du bridge doit être dans le réseau indiqué par le netmask.

Cette conf fonctionne :

enough-ext 12152894-88c7-4ac3-8a84-6837c81cac46

Before going into this, it would simplify the setup if the hypervisor itself did not use an IP from the 37.9.143.x range. So that firewall rules specific to 37.9.143.x for the purpose of allowing access to the VMs are independent of the firewall rules that relate to the hypervisor.

What do you think?

Effectivment, ça nous faciliterait la tâche, au niveau de la définition du réseau virtuel enough-ext aussi. J'ai fait quelques essais en gardant le même réseau mais libvirt bloque quand il détecte que l'hyperviseur a déjà une IP sur le réseau qu'on essaie de créer :

root@gna-hyp-01:~# virsh net-start --network enough-ext
error: Failed to start network enough-ext
error: internal error: Network is already in use by interface bond0
‎27/10/2022 | 09:45:09 ‎rlaguerre‎: root@gna-hyp-01:~# virsh net-dumpxml --network enough-ext

enough-ext
12152894-88c7-4ac3-8a84-6837c81cac46










https://forum.gna.org/t/provide-a-libvirt-hypervisor-for-the-fleet/157/14 [Ouvrir l'URL] And now it obtains an IP from the expected range :tada: one step forward. [ 4.9] Installing firstboot command: env PORT=22 ROUTED=enp1s0 NOT_ROUTED=enp2s0 UNCONFIGURED=noname bash -x /root/network.sh try-host: creating host Starting install... Domain creation completed. try-host: waiting for ipv4 to be allocated Libvirt.get_ipv4: interfaceAddresses returned {}, Retrying in 1 seconds... Libvirt.get_ipv4: interfaceAddresses returned {}, Retrying in 2 seconds... Libvirt.get_ipv4: interfaceAddresses returned {}, Retrying in 4 seconds... Libvirt.get_ipv4: interfaceAddresses returned {}, Retrying in 8 seconds... try-host: waiting for 37.9.143.6:22 to come up Check if SSH is available on 37.9.143.6:22 SSH.wait_for_ssh: [Errno 113] No route to host, Retrying in 1 seconds... The firewall is probably blocking some more and preventing communication with port 22. En fait c'était un problème au niveau de la configuration du virtual network enough-ext. L'IP du bridge doit être dans le réseau indiqué par le netmask. Cette conf fonctionne : <network> <name>enough-ext</name> <uuid>12152894-88c7-4ac3-8a84-6837c81cac46</uuid> <forward dev='bond0' mode='route'> <interface dev='bond0'/> </forward> <bridge name='virbrenough-ext' stp='on' delay='0'/> <mac address='52:54:00:c0:26:d7'/> <ip address='37.9.143.5' netmask='255.255.255.252'> <dhcp> <range start='37.9.143.6' end='37.9.143.6'/> </dhcp> </ip> </network> Before going into this, it would simplify the setup if the hypervisor itself did not use an IP from the 37.9.143.x range. So that firewall rules specific to 37.9.143.x for the purpose of allowing access to the VMs are independent of the firewall rules that relate to the hypervisor. What do you think? Effectivment, ça nous faciliterait la tâche, au niveau de la définition du réseau virtuel enough-ext aussi. J'ai fait quelques essais en gardant le même réseau mais libvirt bloque quand il détecte que l'hyperviseur a déjà une IP sur le réseau qu'on essaie de créer : root@gna-hyp-01:~# virsh net-start --network enough-ext error: Failed to start network enough-ext error: internal error: Network is already in use by interface bond0 ‎27/10/2022 | 09:45:09 ‎rlaguerre‎: root@gna-hyp-01:~# virsh net-dumpxml --network enough-ext <network> <name>enough-ext</name> <uuid>12152894-88c7-4ac3-8a84-6837c81cac46</uuid> <forward dev='bond0' mode='route'> <interface dev='bond0'/> </forward> <bridge name='virbrenough-ext' stp='on' delay='0'/> <mac address='52:54:00:c0:26:d7'/> <ip address='37.9.143.3' netmask='255.255.255.240'> <dhcp> <range start='37.9.143.4' end='37.9.143.14'/> </dhcp> </ip> </network>
easter-eggs started working 2022-10-27 11:04:48 +00:00
easter-eggs stopped working 2022-10-27 11:04:53 +00:00
5 seconds
easter-eggs added spent time 2022-10-27 11:05:01 +00:00
2 hours

=> J'ai fait ça : l'IP de l'hyperviseur est 37.9.139.9 résolvable par gna-hyp-01.pec.cst.easter-eggs.com. Les IPs de 37.9.143.0/28 sont réservées aux VMs.

J'ai testé avec la conf libvirt suivante :

root@gna-hyp-01:~# virsh net-dumpxml --network enough-ext 
<network connections='1'>
  <name>enough-ext</name>
  <uuid>12152894-88c7-4ac3-8a84-6837c81cac46</uuid>
  <forward dev='bond0' mode='route'>
    <interface dev='bond0'/>
  </forward>
  <bridge name='virbrenough-ext' stp='on' delay='0'/>
  <mac address='52:54:00:c0:26:d7'/>
  <ip address='37.9.143.1' netmask='255.255.255.240'>
    <dhcp>
      <range start='37.9.143.2' end='37.9.143.14'/>
    </dhcp>
  </ip>
</network>
=> J'ai fait ça : l'IP de l'hyperviseur est 37.9.139.9 résolvable par gna-hyp-01.pec.cst.easter-eggs.com. Les IPs de 37.9.143.0/28 sont réservées aux VMs. J'ai testé avec la conf libvirt suivante : ``` root@gna-hyp-01:~# virsh net-dumpxml --network enough-ext <network connections='1'> <name>enough-ext</name> <uuid>12152894-88c7-4ac3-8a84-6837c81cac46</uuid> <forward dev='bond0' mode='route'> <interface dev='bond0'/> </forward> <bridge name='virbrenough-ext' stp='on' delay='0'/> <mac address='52:54:00:c0:26:d7'/> <ip address='37.9.143.1' netmask='255.255.255.240'> <dhcp> <range start='37.9.143.2' end='37.9.143.14'/> </dhcp> </ip> </network> ```
easter-eggs added spent time 2022-11-08 13:34:30 +00:00
5 hours 15 minutes
Sign in to join this conversation.
There is no content yet.