3.1. Openstack Training Labs
- 1. Openstack Training Labs
- 2. Configuration et installation de stacktrain
- 2.1. Instructions de virtualisation activées sur l'hôte de virtualisation
- 2.2. Installation de Virtualbox
- 2.3. Installation Libvirt/KVM
- 2.4. Résolution de noms
- 2.5. Configuration du code stacktrain
- 2.6. Déploiement de stacktrain avec Virtualbox
- 2.7. Fin de l'installation avec Virtualbox
- 2.8. Déploiement de stacktrain avec KVM
- 2.9. Fin de l'installation avec KVM
- 2.10. Fichiers de logs
- 2.11. Ajout de règles de pare-feu et du NAT/PAT
- 3. Gestion des noeuds Virtualbox
- 3.1. Lister les noeuds Virtualbox
- 3.2. Démarrer un noeud Virtualbox
- 3.3. Éteindre un noeud Virtualbox
- 3.4. Sauvegarder l'état et stopper un noeud Virtualbox
- 3.5. Gérer les instantanés (snapshots) Virtualbox
- 3.6. Prendre un instantané Virtualbox
- 3.7. Restaurer un instantané Virtualbox
- 3.8. Supprimer un instantané Virtualbox
- 4. Gestion des noeuds QEMU/KVM
- 4.1. Lister les noeuds QEMU/KVM
- 4.2. Prise d'information sur le noeud controller
- 4.3. Prise d'information sur compute1
- 4.4. Réseau KVM
- 4.5. Démarrer un noeud QEMU/KVM
- 4.6. Éteindre un noeud QEMU/KVM
- 4.7. Sauvegarder l'état et stopper un noeud QEMU/KVM
- 4.8. Gérer les instantanés (snapshots) QEMU/KVM
- 4.9. Prendre un instantané QEMU/KVM
- 4.10. Restaurer un instantané QEMU/KVM
- 4.11. Supprimer un instantané QEMU/KVM
- 5. Script d'arrêt / démarrage du cluster
- 6. Script de nettoyage
Installation sur un serveur Scaleway C2L 8 CPUs, 32 Go RAM
1. Openstack Training Labs
Le script python st.py lance osbash qui automatise en bash l'installation d'Openstack. Le dossier source contient plusieurs fichiers et dossiers :
- autostart : Les scripts shell osbash/wbatch (
*.sh) dans ce dossier sont automatiquement exécutés et puis retirés au démarrage. - config : Contient les fichiers de configuration pour tous les scripts. C'est l'endroit de configuration.
- img : Emplacement par défaut des images.
- lib : Librairies utilisées par les scripts.
- log: Contient tous les logs osbash/wbatch exécutés.
log/stacktrain.log - scripts: Tous les scripts qui seront exécutés dans les VMs.
- wbatch : Fichiers batch Windows générés par osbash.
1.1. Description du modèle
Ce déploiement est fonctionnel en plus ou moins une heure sous Ubuntu 18.04 avec VirtualBox 5.2.18 en version Spike.
Il utilise hyperviseur type 2 (VirtualBox) ou type 1 (Qemu/KVM) et des scripts Python et Bash pour simuler un déploiement automatisé proche de la réalité.
Le script st.py déploie la solution en deux temps :
- Une image de base est construite
- Un noeud de contrôle et un noeud de calcul sont installés et configurés pour un usage immédiat.
Dans ce document, l'auteur s'est référé au travail de Diarmuid O'Briain (netLabs!UG OpenStack user group) : OpenStack Laboratory Guide v5.0.1.
Le déploiement se déroule par une connexion SSH qui exécute à chaque étape un script généré sur base de modèles. Les fichiers de logs nous renseigneront sur ces étapes.
1.2. Topologie / architecture
Cette topologie comporte deux noeuds (Compute1 et Controller) qui se connectent à trois réseaux :
| Nom du réseau | Plage d'adresse | Usage |
|---|---|---|
| Management | 10.0.0.0/24 | C'est le réseau qui assure la communication interne entre les noeuds |
| Provider | 203.0.113.0/24 | C'est le réseau qui offre un accès Internet aux VMs créées |
| LAN (Public) | dépendant | C'est le réseau qui offre un accès Internet aux noeuds |
Un troisième noeud Compute2 viendra s'ajouter à la topologie de départ dans un prochain exercice.
1.3. Dimensionnement
On réservera 2048 Mo de RAM pour l'hôte physique sur un total de 32 Go de RAM.
Le contrôleur devrait disposer de 6144 Mo de RAM et de 2 CPUs dans cette configuration. Lui accorder 8 Go de RAM ne serait pas un luxe.
Un minimum de 1 CPU et de 1536 Mo de RAM est nécessaire pour le noeud de calcul, mais il n'y a pas de limite haute évidemment. On conseille de réserver aux noeuds de calcul 8 Go de RAM, 4 CPUs et 128 Go de disque (qui sera approvisionné de manière légère et mis en snapshot initial).
| Fichier | VM_MEM | VM_CPU | SECOND_DISK_SIZE |
|---|---|---|---|
config.controller |
6144 | 2 | N/A |
config.compute1 |
8192 | 4 | 128000 |
Il reste encore 16384 Mo de RAM pour ajouter un ou deux noeuds supplémentaires.
1.4. Noeud Controller
Le noeud de contrôle (Controller) exécute les services OpenStack suivants :
- Keystone, le service d'identification
- Glance, le service d'images
- La gestion des services :
- Nova, le service de calcul
- Neutron, le service réseau
- Horizon, le service de panneau de contrôle
- des services :
- Base de données SQL (MySQL)
- Messages Queuing (RabbitMQ)
- Synchronisation temporelle (NTP)
On peut y installer d'autres services comme :
- Cinder, le service de stockage de type "block"
- Swift, le service de stockage de type "objet"
- Heat, le service d'orchestration
- Ceilometer, des services de télémétrie
1.5. Noeud Compute (calcul)
Ce type de noeud héberge un hyperviseur Qemu/KVM pour exécuter les machines virtuelles.
... un mot sur le réseau avec Neutron ...
1.6. Mots de passe des services
| Function | Name | Database Pass | Domain Pass | User Pass |
|---|---|---|---|---|
| MySQL | root | secrete | ||
| RabbitMQ | rabbitPass | |||
| Ceilometer | ceilometer | ceilometer_db_secret | ceilometer_user_secret | |
| Cinder | cinder | cinder_db_secret | cinder_user_secret | |
| Glance | glance | glance_db_secret | glance_user_secret | |
| Heat | heat | heat_db_secret | heat_dom_pw | heat_user_secret |
| Keystone | keystone | keystone_db_secret | ||
| Neutron | neutron | neutron_db_secret | neutron_user_secret | |
| Nova | nova | nova_db_secret | nova_user_secret |
1.7. Comptes utilisateurs par projet
| Project name | Username | Password | User role name |
|---|---|---|---|
| admin | admin | admin_user_secret | admin |
| demo | demo | demo_user_pass | User |
| CirrOS VM test | cirros | cubswin:) |
2. Configuration et installation de stacktrain
Une connexion SSH est nécessaire pour administrer notre solution. L'option -i indique le chemin de la d'authentification de l'utilisateur stack qui se connecte au serveur yourhost
Pour obtenir une console graphique nécessaire à l'usage de KVM dans notre cas, il faut installer localement un serveur X11 (Xming pour Windows) et lancer une connexion SSH avec l'option -MY de transfert de sessions graphiques. L'option -M Place le client SSH en mode maître pour le partage de connexion et l'option -Y active le transfert X11 de confiance. Les redirections X11 de confiance ne sont alors pas soumises aux contrôles d'extension X11 SECURITY.
Les noeuds "controller" et "compute1" sont des machines virtuelles que le gestionnaire de VMs lancent. Pour l'instant les scripts lancent les VMs avec une console graphique, mais les installations sont silencieuses et journalisées.
ssh -MY -i yourbox-id_rsa.pem stack@yourhost
2.1. Instructions de virtualisation activées sur l'hôte de virtualisation
Pour prendre en charge les invités HVM (Hardware-assisted Virtual Machine), les extensions de virtualisation doivent être activées dans le (BIOS) :
- Enable Virtualisation Technology - x86 architectures (VT-x)
- Enable Intel VT
- Vanderpool Technology
Aussi, il est nécessaire d'activer :
- Intel Virtualisation Technology for Directed I/O (VT-d)
Pour confirmer que la virtualisation matérielle est activée, on exécute une recherche sur les mots clés "VMX" (Intel) ou "SVM" (AMD) :
Cette commande identifie les motifs vmx ou svm dans le fichier du noyau /proc/cpuinfo et rend le nombre d'occurences trouvées
sudo egrep -c 'vmx|svm' /proc/cpuinfo
8
Ou encore :
sudo lscpu | grep 'Virtualization'
Virtualization: VT-x
Sur un hôte KVM :
sudo virt-host-validate
2.2. Installation de Virtualbox
sudo apt-get update
sudo apt-get -y upgrade
sudo apt-get -y install virtualbox
2.3. Installation Libvirt/KVM
sudo apt-get update
sudo apt-get -y upgrade
sudo apt-get -y install qemu-kvm libvirt-bin virtinst virt-viewer libguestfs-tools virt-manager uuid-runtime python-pip pkg-config libvirt-dev genisoimage netcat python-dev libyaml-dev libosinfo-bin virt-top
sudo usermod -aG libvirt `id -un`
2.4. Résolution de noms
Quel que soit l'hyperviseur choisi la résolution des noms sur l'hôte de virtualisation doit être assurée :
cat << EOF | sudo tee --append /etc/hosts
# ------------------
# Virtualised nodes
# ------------------
# controller
10.0.0.11 controller
# compute1
10.0.0.31 compute1
# compute1
10.0.0.32 compute2
EOF
2.5. Configuration du code stacktrain
Entrer dans une session comme utilisateur stack :
sudo su - stack
Le script rudimentaire suivant installe les scripts de "training-labs" selon la version et configure l'environnement de déploiement.
#!/bin/bash
#st_setup.sh
package=$1
case ${package} in
pike)
archive="labs-stable-pike.tgz" ;;
queens)
archive="labs-stable-queens.tgz" ;;
rocky)
archive="labs-stable-rocky.tgz" ;;
stein)
archive="labs-master.tgz" ;;
*)
head -n15 $0 && exit ;;
esac
echo "---- Get the training-labs scripts ----"
wget http://tarballs.openstack.org/training-labs/dist/${archive}
tar xvfz ${archive}
echo "---- Configure directory path as env variables ----"
cat << EOF >> ~/.bashrc
OS_LAB=$HOME
OS_ST=$HOME/labs
OS_BASH=$HOME/labs/osbash
EOF
export OS_LAB=$HOME
export OS_ST=$HOME/labs
export OS_BASH=$HOME/labs/osbash
echo "---- Configure the controller and the compute1 components ----"
mv $OS_ST/config/config.controller $OS_ST/config/config.controller.bak
cat << EOF >> $OS_ST/config/config.controller
VM_SSH_PORT=2230
VM_WWW_PORT=8888
NET_IF_0=dhcp
NET_IF_1="static 10.0.0.11 1"
NET_IF_2="manual 203.0.113.0"
VM_MEM=6144
VM_CPUS=2
EOF
mv $OS_ST/config/config.compute1 $OS_ST/config/config.compute1.bak
cat << EOF >> $OS_ST/config/config.compute1
VM_SSH_PORT=2232
NET_IF_0=dhcp
NET_IF_1="static 10.0.0.31 1"
NET_IF_2="manual 203.0.113.0"
SECOND_DISK_SIZE=128000
VM_MEM=8192
VM_CPUS=4
EOF
cat << EOF | sudo tee --append /etc/hosts
10.0.0.11 controller
10.0.0.31 compute1
EOF
if [ ${package} == "pike" ] ; then
echo "---- Enable Heat service installation ----"
cp $OS_ST/config/scripts.ubuntu_cluster $OS_ST/config/scripts.ubuntu_cluster.bak
sed -i '/heat_controller/s/#//' $OS_ST/config/scripts.ubuntu_cluster
fi
if [ $(virsh --version > /dev/null ; echo $?) == '0' ] ; then
echo "---- install last prereq ----"
sudo apt update
sudo apt -qq install iptables-converter
echo "---- Default Storage Pool creation ----"
sudo virsh pool-destroy default
sudo virsh pool-undefine default
mkdir -p /home/stack/labs/pool
sudo virsh pool-define-as default dir - - - - "/home/stack/labs/pool"
sudo virsh pool-start default
sudo virsh pool-autostart default
echo "---- Populate env vars ----"
cat << EOF >> ~/.bashrc
VIRSH_DEFAULT_CONNECT_URI='qemu:///system'
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
EOF
export PATH=$PATH:/sbin:/usr/sbin/
echo "---- install last prereq ----"
sudo apt update
sudo apt -qq install iptables-converter
echo "---- Default Storage Pool creation ----"
sudo virsh pool-destroy default
sudo virsh pool-undefine default
mkdir -p /home/stack/labs/pool
sudo virsh pool-define-as default dir - - - - "/home/stack/labs/pool"
sudo virsh pool-start default
sudo virsh pool-autostart default
echo "---- Populate env vars ----"
cat << EOF >> ~/.bashrc
VIRSH_DEFAULT_CONNECT_URI='qemu:///system'
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
EOF
export PATH=$PATH:/sbin:/usr/sbin/
fi
- controller : 6Go RAM, 2 CPUs, 10.0.0.11/24 et 203.0.113.0/24
- compute1 : 8Go RAM, 4 CPUs 10.0.0.31/24 et 203.0.113.0/24
- release :
- pike
- rocky
- queens
- stein
| versions | KVM | Virtualbox |
|---|---|---|
| pike | testé | testé |
| rocky | ||
| queens | ||
| stein | échec | échec |
La version "spike" a été testée sous Virtualbox :
bash st_setup.sh spike
La version "pike" a été testée sous KVM :
bash st_setup.sh pike
2.6. Déploiement de stacktrain avec Virtualbox
sudo su - stack
cd labs
./st.py --verbose-console -b --verbose cluster
2.7. Fin de l'installation avec Virtualbox
Le déploiement se termine par ce message :
11:01:29 21750 INFO Cluster build took 2688 seconds
Your cluster nodes:
11:01:29 21750 INFO VM name: compute1
11:01:29 21750 INFO SSH login: ssh -p 2232 osbash@127.0.0.1
11:01:29 21750 INFO (password: osbash)
11:01:29 21750 INFO VM name: controller
11:01:29 21750 INFO SSH login: ssh -p 2230 osbash@127.0.0.1
11:01:29 21750 INFO (password: osbash)
11:01:29 21750 INFO Dashboard: Assuming horizon is on controller VM.
11:01:29 21750 INFO http://127.0.0.1:8888/horizon/
11:01:29 21750 INFO User : demo (password: demo_user_pass)
11:01:29 21750 INFO User : admin (password: admin_user_secret)
11:01:29 21750 INFO Network: mgmt
11:01:29 21750 INFO Network address: 10.0.0.0
11:01:29 21750 INFO Network: provider
11:01:29 21750 INFO Network address: 203.0.113.0
Ce déploiement a duré 44 minutes 48 secondes.
2.8. Déploiement de stacktrain avec KVM
cd labs
./st.py --verbose-console -b --verbose --provider kvm cluster
2.9. Fin de l'installation avec KVM
Le déploiement se termine par ce message :
22:03:59 26102 INFO Cluster build took 3143 seconds
Your cluster nodes:
22:03:59 26102 INFO VM name: compute1
22:03:59 26102 INFO SSH login: ssh osbash@192.168.122.103
22:03:59 26102 INFO (password: osbash)
22:03:59 26102 INFO VM name: controller
22:03:59 26102 INFO SSH login: ssh osbash@192.168.122.117
22:03:59 26102 INFO (password: osbash)
22:03:59 26102 INFO Dashboard: Assuming horizon is on controller VM.
22:03:59 26102 INFO http://192.168.122.117/horizon/
22:03:59 26102 INFO User : demo (password: demo_user_pass)
22:03:59 26102 INFO User : admin (password: admin_user_secret)
22:03:59 26102 INFO Network: mgmt
22:03:59 26102 INFO Network address: 10.0.0.0
22:03:59 26102 INFO Network: provider
22:03:59 26102 INFO Network address: 203.0.113.0
Ce déploiement a duré 52 minutes 23 secondes.
2.10. Fichiers de logs
Les fichiers de logs situés dans $OS_LAB/labs/logs rappellent les différentes étapes du déploiement.
- 000_00_base_fixups.auto
- 001_01_apt_init.auto
- 002_02_apt_upgrade.auto
- 003_03_pre-download.auto
- 004_04_apt_pre-download.auto
- 005_05_enable_osbash_ssh_keys.auto
- 006_06_zero_empty.auto
- 007_07_shutdown.auto
- 008_00_init_controller_node.auto
- 009_01_etc_hosts.auto
- 010_02_enable_osbash_ssh_keys.auto
- 011_03_copy_openrc.auto
- 012_04_apt_install_mysql.auto
- 013_05_install_rabbitmq.auto
- 014_06_install_memcached.auto
- 015_07_setup_keystone.auto
- 016_08_get_auth_token.auto
- 017_09_setup_glance.auto
- 018_10_setup_nova_controller.auto
- 019_11_setup_neutron_controller.auto
- 020_12_setup_self-service_controller.auto
- 021_13_setup_neutron_controller_part_2.auto
- 022_14_setup_horizon.auto
- 023_15_setup_cinder_controller.auto
- 024_16_setup_heat_controller.auto
- 025_00_init_compute1_node.auto
- 026_01_etc_hosts.auto
- 027_02_enable_osbash_ssh_keys.auto
- 028_03_copy_openrc.auto
- 029_04_setup_nova_compute.auto
- 030_05_setup_neutron_compute.auto
- 031_06_setup_self-service_compute.auto
- 032_07_setup_neutron_compute_part_2.auto
- 033_08_setup_cinder_volumes.auto
- 034_00_config_public_network.auto
- 035_01_config_private_network.auto
On trouvera d'autres fichiers au même endroit comme ceux-ci :
- ssh.log
- stacktrain.log
- status
- vboxmanage.log
- vm_base.cfg
- vm_compute1.cfg
- vm_controller.cfg
2.11. Ajout de règles de pare-feu et du NAT/PAT
Afin de donner accès au réseau "Provider" à l'Internet et à ses indispensables services, il est à notre charge de simuler cette connectivité comme si on s'organisait avec les personnes en charge de l'infrastructure du réseau pour établir cette connectivité avec des commutateurs et des routeurs physiques.
Pour notre part, il s'agit d'autoriser (via le script suivant) le routage IP du réseau "provider" représenté par le nom de l'interface virtuelle qui le supporte vers l'Internet représenté par le nom de l'interface physique qui connecte l'hôte de virtualisation, ici "eth0". Le nom de l'interface virtuelle dépend de la solution de virtualisation choisie.
Le script met en place un pare-feu qui n'autorise que le trafic de réponses légitimes de le traverser.
Aussi, il active la traduction d'adresse IPv4 (NAT, Network Adress Translation) avec une méthode de "MASQUERADING" qui signifie "masquer". En effet, cette méthode consiste à remplacer l'adresse IP source de l'émetteur dont le réseau est inconnu du reste de l'Internet par l'adresse d'une interface qui dispose d'une connectivité (de routage vers) Internet. On dit que l'adresse et son réseau est caché car derrière une seule adresse, un grand nombre peuvent se cacher. Pour en terminer sur cette succincte présentation du NAT, on se demandera comment une telle traduction de multiples adresses à partir d'une seule est possible ? Le routage NAT utilise le port source comme critère de traduction en plus de l'adresse IPv4 source, on parle alors de "Source NAT" et de "PAT (Port Adress Translation)", ce qui permet de multiplexer le trafic à partir d'une seule adresse de traduction.
cat <<'EOM' > $OS_LAB/nat_tables.sh
#!/bin/bash
###########################################
# program: nat_tables.sh #
# Author: Diarmuid O'Briain #
# Copyright ©2017 C2S Consulting #
# License: www.gnu.org/licenses/gpl.txt #
###########################################
# NAT masquerade rules for hypervisor, hosting OpenStack testbed #
# Select interface, typically 'wlp4s0' for WIFI and 'enp0s3' for wired Ethernet
INTERFACE=eth0 # Unhash for wired Ethernet interface
#INTERFACE=enp3s0 # Unhash for wired Ethernet interface
#INTERFACE=wlp4s0 # Unhash for wireless WIFI interface
# Select instance private network
#NETWORK=virbr2
NETWORK=vboxnet1
# Flush iptables
iptables -F
iptables -F -t nat
# Enable IP forwarding
# For KVM/QEMU
# For VirtualBox
echo
echo "echo \"1\" > /proc/sys/net/ipv4/ip_forward"
echo "1" > /proc/sys/net/ipv4/ip_forward
echo
# Load GNU/Linux kernel modules
modprobe ip_tables
modprobe ip_conntrack
# Add IPTABLES rules
iptables -t nat -A POSTROUTING -o $INTERFACE -j MASQUERADE
iptables -A FORWARD -i $INTERFACE -o $NETWORK -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $NETWORK -o $INTERFACE -j ACCEPT
# Print iptables
iptables -t nat -v -L POSTROUTING
echo
iptables -v -L FORWARD
# END
EOM
À exécuter avec des privilèges :
chmod +x $OS_LAB/nat_tables.sh
sudo $OS_LAB/nat_tables.sh
echo "1" > /proc/sys/net/ipv4/ip_forward
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- any eth0 anywhere anywhere
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- eth0 vboxnet1 anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT all -- vboxnet1 eth0 anywhere anywhere
3. Gestion des noeuds Virtualbox
Manipulation des noeuds avec VirtualBox en ligne de commande.
3.1. Lister les noeuds Virtualbox
vboxmanage list vms
vboxmanage list runningvms
3.2. Démarrer un noeud Virtualbox
vboxmanage startvm "controller" --type headless
vboxmanage startvm "compute1" --type headless
3.3. Éteindre un noeud Virtualbox
vboxmanage controlvm "controller" poweroff
vboxmanage controlvm "compute1" poweroff
3.4. Sauvegarder l'état et stopper un noeud Virtualbox
vboxmnage controlvm "compute1" savestate
3.5. Gérer les instantanés (snapshots) Virtualbox
vboxmanage snapshot "controller" list
3.6. Prendre un instantané Virtualbox
vboxmanage snapshot "controller" take "snap01-controller" --description "Initial controller snapshot"
3.7. Restaurer un instantané Virtualbox
vboxmanage controlvm "controller" poweroff
vboxmanage snapshot "controller" restore snap01-controller
3.8. Supprimer un instantané Virtualbox
vboxmanage snapshot "controller" delete snap01-controller
4. Gestion des noeuds QEMU/KVM
Manipulation des noeuds avec libvirt en ligne de commande virsh.
4.1. Lister les noeuds QEMU/KVM
stack@stacktrain05:~/labs$ sudo virsh list --all
Id Name State
----------------------------------------------------
6 controller running
7 compute1 running
4.2. Prise d'information sur le noeud controller
stack@stacktrain05:~/labs$ sudo virsh dominfo controller
Id: 6
Name: controller
UUID: 7f21ec82-7aba-4627-9612-f42c4b5d4500
OS Type: hvm
State: running
CPU(s): 2
CPU time: 926.2s
Max memory: 6291456 KiB
Used memory: 6291456 KiB
Persistent: yes
Autostart: disable
Managed save: no
Security model: apparmor
Security DOI: 0
Security label: libvirt-7f21ec82-7aba-4627-9612-f42c4b5d4500 (enforcing)
stack@stacktrain05:~/labs$ sudo virsh snapshot-list controller
Name Creation Time State
------------------------------------------------------------
controller_-_cluster_installed 2019-03-06 22:02:37 +0000 shutoff
4.3. Prise d'information sur compute1
stack@stacktrain05:~/labs$ sudo virsh dominfo compute1
Id: 7
Name: compute1
UUID: 0118dad7-90ca-405a-bbf2-c2c09c61046c
OS Type: hvm
State: running
CPU(s): 4
CPU time: 379.7s
Max memory: 8388608 KiB
Used memory: 8388608 KiB
Persistent: yes
Autostart: disable
Managed save: no
Security model: apparmor
Security DOI: 0
Security label: libvirt-0118dad7-90ca-405a-bbf2-c2c09c61046c (enforcing)
stack@stacktrain05:~/labs$ sudo virsh snapshot-list compute1
Name Creation Time State
------------------------------------------------------------
compute-_cluster_installed 2019-03-06 22:02:37 +0000 shutoff
4.4. Réseau KVM
default
stack@stacktrain05:~/labs$ sudo virsh net-dumpxml default
<network>
<name>default</name>
<uuid>8a1cc0eb-5ad8-438e-aa82-70a03e15de0b</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:12:a2:f3'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
labs-mgmt
stack@stacktrain05:~/labs$ sudo virsh net-dumpxml labs-mgmt
<network connections='2'>
<name>labs-mgmt</name>
<uuid>c3ce06a7-519b-4126-931f-537c35c2172c</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr1' stp='on' delay='0'/>
<mac address='52:54:00:2b:d5:f8'/>
<ip address='10.0.0.1' netmask='255.255.255.0'>
</ip>
</network>
labs-provider
stack@stacktrain05:~/labs$ sudo virsh net-dumpxml labs-provider
<network connections='2'>
<name>labs-provider</name>
<uuid>325aba62-c62e-44d2-874b-c904ea1f5fcb</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr2' stp='on' delay='0'/>
<mac address='52:54:00:9e:59:fa'/>
<ip address='203.0.113.1' netmask='255.255.255.0'>
</ip>
</network>
4.5. Démarrer un noeud QEMU/KVM
sudo virsh start controller
4.6. Éteindre un noeud QEMU/KVM
sudo virsh shutdown controller
4.7. Sauvegarder l'état et stopper un noeud QEMU/KVM
sudo virsh save compute1 compute1.dump
4.8. Gérer les instantanés (snapshots) QEMU/KVM
sudo virsh snapshot-list controller
Name Creation Time State
------------------------------------------------------------
controller_-_cluster_installed 2019-03-06 22:02:37 +0000 shutoff
4.9. Prendre un instantané QEMU/KVM
sudo virsh
4.10. Restaurer un instantané QEMU/KVM
sudo virsh
4.11. Supprimer un instantané QEMU/KVM
sudo virsh
5. Script d'arrêt / démarrage du cluster
Script start-stop-cluster.sh
cat <<'EOM' > ~/start-stop-cluster.sh
#!/bin/bash
###########################################
# program: start-stop-cluster.sh #
# Author: Diarmuid O'Briain #
# Copyright ©2017 C2S Consulting #
# License: www.gnu.org/licenses/gpl.txt #
###########################################
PROVIDER=''
if [[ `echo "$0" | grep './'` ]]; then
command=`echo "$0"|awk -F '/' '{print $2}'`
else
command=$0
fi
# Help function
function usage {
echo -e "usage: $command <PROVIDER> <START | STOP> help, -h, -help, --help\n"
echo -e "PROVIDER:: kvm | vbox\n"
echo -e "kvm = Kernel based Virtual Machine/Quick Emulator (KVM/QEMU)\n"
echo -e "vbox = Oracle VirtualBox\n"
echo -e "Start or Stop the Virtual Machines in the cluster\n"
exit
}
# Arguments from the command line
if [[ $# -lt 1 ]]; then # Deal with too few arguments
echo -e "\nNot enough arguments\n"
usage
elif [[ $# -gt 2 ]]; then # Deal with too many arguments
echo -e "\nToo many arguments\n"
usage
elif [[ $1 =~ (-h|-help|--help|help) ]]; then # Deal with request for help
usage
elif [[ $1 =~ (kvm|vbox) ]] && [[ $2 =~ (start|stop) ]]; then # Deal with legit option
PROVIDER=$1
ACTION=$2
echo -e "\nSelected provider is: $PROVIDER and the cluster will $ACTION\n"
else
echo -e "\nNot an acceptable option\n"
usage
fi
# Action nodes
if [[ $PROVIDER =~ 'kvm' ]] && [[ $ACTION =~ 'start' ]]; then
echo -e "Powering up KVM/QEMU nodes\n"
if ! [[ $(virsh net-list | egrep 'labs-mgmt|labs-provider'; echo $?) ]];then
virsh -c 'qemu:///system' net-start 'labs-mgmt'
virsh -c 'qemu:///system' net-start 'labs-provider'
fi
sleep 5
virsh -c 'qemu:///system' start 'controller'
virsh -c 'qemu:///system' start 'compute1'
elif [[ $PROVIDER =~ 'kvm' ]] && [[ $ACTION =~ 'stop' ]]; then
echo -e "Powering down KVM/QEMU nodes\n"
virsh -c 'qemu:///system' shutdown 'controller'
virsh -c 'qemu:///system' shutdown 'compute1'
sleep 5
elif [[ $PROVIDER =~ 'vbox' ]] && [[ $ACTION =~ 'start' ]]; then
echo -e "Powering up VirtualBox nodes\n"
vboxmanage startvm 'controller' --type headless
vboxmanage startvm 'compute1' --type headless
echo
elif [[ $PROVIDER =~ 'vbox' ]] && [[ $ACTION =~ 'stop' ]]; then
echo -e "Powering off VirtualBox nodes\n"
vboxmanage controlvm 'controller' poweroff
vboxmanage controlvm 'compute1' poweroff
echo
fi
# Show cluster
echo -e "Cluster state\n"
if [[ $PROVIDER =~ 'kvm' ]] && [[ $ACTION =~ 'stop' ]]; then
while true; do
listout=$(virsh -c 'qemu:///system' list)
if ! [[ $(echo $listout |egrep 'controller|compute1') ]]; then
break
fi
echo -n '. ';sleep 2
done
echo
virsh -c 'qemu:///system' net-list
virsh -c 'qemu:///system' list
elif [[ $PROVIDER =~ 'kvm' ]] && [[ $ACTION =~ 'start' ]]; then
virsh -c 'qemu:///system' net-list
virsh -c 'qemu:///system' list
elif [[ $PROVIDER =~ 'vbox' ]] && [[ $ACTION =~ 'start' ]]; then
echo 'Running VMs'
vboxmanage list runningvms | egrep 'controller|compute1'
else
echo 'VMs in a shutdown state'
vboxmanage list vms | egrep 'controller|compute1'
echo
fi
# END
EOM
chmod +x ~/start-stop-cluster.sh
~/start-stop-cluster.sh
Not enough arguments
usage: opt <PROVIDER> <START | STOP> help, -h, -help, --help
PROVIDER:: kvm | vbox
kvm = Kernel based Virtual Machine/Quick Emulator (KVM/QEMU)
vbox = Oracle VirtualBox
Start or Stop the Virtual Machines in the cluster
~/start-stop-cluster.sh vbox start
~/start-stop-cluster.sh vbox stop
6. Script de nettoyage
Ce script remet le lab dans son état initial.
cat <<'EOM' > $OS_LAB/clean_nodes.sh
#!/bin/bash
###########################################
# program: clean_nodes.sh #
# Author: Diarmuid O'Briain #
# Copyright ©2017 C2S Consulting #
# License: www.gnu.org/licenses/gpl.txt #
###########################################
PROVIDER=''
if [[ `echo "$0" | grep './'` ]]; then
command=`echo "$0"|awk -F '/' '{print $2}'`
else
command=$0
fi
# Help function
function usage {
echo -e "usage: $command <PROVIDER> help, -h, -help, --help\n"
echo -e"PROVIDER:: kvm | vbox\n"
echo -e"kvm = Kernel based Virtual Machine/Quick Emulator (KVM/QEMU)\n"
echo -e"vbox = Oracle VirtualBox\n"
echo -e"Note: For KVM/QEMU this command must be ran as sudo\n"
exit
}
# Arguments from the command line
if [[ $# -lt 1 ]]; then # Deal with too few arguments
echo -e "\nNot enough arguments\n"
usage
elif [[ $# -gt 1 ]]; then # Deal with too many arguments
echo -e "\nToo many arguments\n"
usage
elif [[ $1 =~ (-h|-help|--help|help) ]]; then # Deal with request for help
usage
elif [[ $1 =~ (kvm|vbox) ]]; then # Deal with legit option
PROVIDER=$1
echo -e "\nSelected provider is: $PROVIDER\n"
else
echo -e "\nNot an acceptable option\n"
usage
fi
echo -e "\nRestoring nodes to clean state\n"
# Powering off nodes
if [[ $PROVIDER =~ 'kvm' ]]; then
echo -e "Powering off KVM/QEMU nodes\n"
virsh -c 'qemu:///system' shutdown 'controller'
virsh -c 'qemu:///system' shutdown 'compute1'
else
echo -e "Powering off VirtualBox nodes\n"
vboxmanage controlvm 'controller' poweroff
vboxmanage controlvm 'compute1' poweroff
fi
# Wait for nodes to power down
echo -e "\nWaiting for nodes to power down completely\n"
if [[ $PROVIDER =~ 'kvm' ]]; then
while [[ 1 ]]; do
CONTROLLER_STATE=`virsh -c 'qemu:///system' list --all | grep -e 'controller\s*shut off' | awk '{print $3, $4}'` COMPUTE_STATE=`virsh -c 'qemu:///system' list --all | grep -e 'compute1\s*shut off' | awk '{print $3, $4}'` printf "."; sleep 2
if [[ $CONTROLLER_STATE =~ 'shut off' && $COMPUTE_STATE =~ 'shut off' ]]; then echo -e "\n\nController node and Compute1 node are in a shut down state"
break
fi
done
else
while [[ 1 ]]; do
CONTROLLER_STATE=`vboxmanage showvminfo 'controller' | \
grep '^State' | awk '{print $2}'`
COMPUTE_STATE=`vboxmanage showvminfo 'controller' | \
grep '^State' | awk '{print $2}'`
printf "."
if [[ $CONTROLLER_STATE =~ 'powered' && $COMPUTE_STATE =~ 'powered' ]]; then
echo -e "\n\nController node and Compute1 node are in a shut down state"
break
fi
done
fi
# Return nodes to last working snapshots
if [[ $PROVIDER =~ 'kvm' ]]; then
echo -e "\nReverting KVM/QEMU nodes to earlier snapshots\n"
virsh -c 'qemu:///system' snapshot-revert --domain 'controller' \
--snapshotname 'controller_-_cluster_installed' --running
virsh -c 'qemu:///system' snapshot-revert --domain 'compute1' \
--snapshotname 'compute-_cluster_installed' --running
else
echo -e "\nReverting VirtualBox nodes to earlier snapshot\n"
vboxmanage snapshot 'controller' restore 'controller_-_cluster_installed'
echo
vboxmanage snapshot 'compute1' restore 'compute-_cluster_installed'
echo
vboxmanage startvm 'controller' --type headless
echo
vboxmanage startvm 'compute1' --type headless
echo
fi
# Show clean nodes
echo -e "Clean running nodes\n"
if [[ $PROVIDER =~ 'kvm' ]]; then
virsh -c 'qemu:///system' list
else
vboxmanage list runningvms
echo
fi
# END
EOM
chmod +x $OS_LAB/clean_nodes.sh
$OS_LAB/clean_nodes.sh
Alternative KVM
virsh shutdown controller
virsh shutdown compute1
virsh snapshot-revert --domain 'controller' --snapshotname 'controller_-_cluster_installed' --running
virsh snapshot-revert --domain 'compute1' --snapshotname 'compute-_cluster_installed' --running