Laboratoires Services réseau
1. Introduction
L’objectif de ce chapitre est de donner une vue générale des services, protocoles et machines (serveurs et clients) à déployer dans des exercices de laboratoire sur les thèmes des services réseau Linux. Ce chapitre tente de montrer comment on peut déployer des topologies entières uniquement en quelques lignes de commande avec un hyperviseur Linux natif tel que KVM.
1.1. Pré-requis de formation
Pour mettre en place les laboratoires sur le thème des services réseau, il est conseillé d’avoir la maîtrise des concepts qui portent sur L’Administration système et plus particulièrement ceux du chapitre sur la Virtualisation KVM.
Alors que l’on rencontre encore souvent des propositions de laboratoires à partir de configurations physiques ou virtualisées sous VMWare ou VirtualBox, on propose ici des exercices à partir de déploiements KVM automatisés.
Mais avant de présenter les méthodes de construction des labs, rappelons les objectifs de ces exercices.
1.2. Services
Dans le cadre de notre propos, on peut considérer qu’il y a au moins une machine à déployer par service offert.
1.3. Dimensionnement
1. Ressources
- Vcpu : nombre (1 à 4)
- Mémoire : quantité 128, 256, 512, 1024, 2048, 4096, 8184 Mo
- Stockage : nombre et quantité 8, 16, 32, 64 Go
- Réseau : nombre et connexion interface/commutateur
2. Types de machines
On peut considérer plusieurs types de machines :
- Les routeurs
- Les hôtes terminaux
Parmi les hôtes terminaux :
- Les serveurs
- Les clients
Parmi les serveurs :
- Serveurs internes
- Serveurs externes
Parmi les hôtes clients :
- Les clients texte
- Les clients graphiques
- Les clients multimedia
- Les stations malveillantes (hacking)
3. Pré-requis en ressources des machines virtuelles
| Machine | Remarque |
|---|---|
| Les routeurs | Réseau : minimum 2 interfaces |
| Les serveurs | Ressources adaptée en mémoire, vcpu et stockage |
| Les clients texte | Ressources minimale |
| Les clients graphiques | plus de mémoire |
| Les clients multimedia | - |
| Les stations malveillantes (hacking) | - |
4. Profilage des machines virtuelles
Voici une proposition de profilage des machines virtuelles.
| Profil | vCPUs (1) | Mémoire RAM (2) | Réseau (3) | Stockage (4) |
|---|---|---|---|---|
| xsmall | 1 | 256 | eth0 : default | 8 Go |
| small | 1 | 512 | eth0 : default | 8 Go |
| medium | 1 | 1024 | eth0 : default | 16 Go |
| big | 2 | 2048 | eth0 : default | 32 Go |
| xbig | 2 | 3072 | eth0 : default | 32 Go |
| xxbig | 4 | 4096 | eth0 : default | 32 Go |
2. Déploiement de machines virtuelles à partir de modèles
L’intérêt d’outils comme libvirt / Qemu / KVM est que l’on peut manipuler, approvisionner, détruire nos composants virtuels (CPU/RAM, stockage, réseau) représentés par des machines virtuelles (des domaines invités) en bas niveau et de manière aisée.
La virtualisation Linux native atteint des niveaux de performances très proches du matériel qui, justement utilisée avec un bon ordinateur, rend les perspectives de laboratoires peut-être complexes au final mais complets, progressifs, faciles à manipuler, à reproduire, à vérifier et à corriger.
Avec ces pratiques, on est très proche à la fois du métier de technicien PC qui tendrait à disparaître des listes officielles des métiers qualifiés et demandés et à la fois de celui d’administrateur de solutions de virtualisation et/ou en nuage (cloud).
Ces différentes opérations sont de bas niveau, peuvent être nombreuses et répétitives selon la complexité de la topologie à reproduire. En ce sens, on encourage ici à automatiser les tâches de déploiement via des scripts bash, python ou autres facilités.
Enfin, ces pratiques avec libvirt / Qemu / KVM invitent à s’intéresser à des solutions comme Ansible, Docker, OpenStack, etc.
Dans un premier, on propose d’utiliser les scipts bash de l’auteur et le logiciel frontal kcli
2.1. Préparation de l’hôte de virtualisation
Sur l’hôte de virtualisation Debian ou RHEL/Centos, en tant qu’utilisateur privilégié, on ira chercher les scripts pouvant être utiles.
yum -y install git || apt-get -y install git
git clone https://github.com/goffinet/virt-scripts
cd virt-scripts
Pour installer les logiciels qui transforment l’ordinateur en hôte de virtualisation, on lancera à partir du dossier virt-scripts en tant que super-utilisateur le script autoprep.sh (https://raw.githubusercontent.com/goffinet/virt-scripts/master/autoprep.sh) :
./autoprep.sh
Le script installe les outils de virtualisation KVM / Qemu / Libvirt / kcli, il active Apache et la Nested Virtualization.
Vérifiez le rapport et redémarrer l’ordinateur :
reboot
1. Terminologie
- Hôte de virtualisation, hyperviseur : Machine physique qui exécute les machines virtuelles. Ici le module du noyau Linux KVM.
- Machine virtuelle, ou domaine invité : fichier de définition qui référence un ou plusieurs disques attachés ainsi que le matériel virtuel.
- Para-virtualisation : technique de virtualisation qui permet au moniteur de machine virtuelle (VMM) de manière plus directe aux prériphériques physiques de l’hôte. Cette technique nécessite que le domaine invité exécute des pilotes spécifiques comme des “VMWare Tools”. Les machines virtuelles Linux exécutent automatiquement ces pilotes.
- Qemu : Emulateur Hardware. KVM gère le CPU/RAM, Qemu autorise la para-virtualisation des périphériques virtuels de communication, graphique, disques et réseau.
- Libvirt : API de contrôle de Qemu / KVM
- LibGuestFs : Outils de manipulation des disques virtuels
-
virsh: principale commande libvirtd -
virt-scripts: ensemble de scripts Bash qui simplifient les procédures de manipulation des machines virtuelle. -
kcli: script avancé en python qui fait front à libvirt. - Image : disque d’une machine virtuelle.
- Modèle : image de base à reproduire (à “cloner”).
2. Virtualisation HVM et “Nested Virtualization”
- Les instructions de virtualisation doivent être activées sur l’hôte de virtualisation, nécessairement physique. Autrement, seule l’émulation “Hardware” (Qemu) du CPU sera disponible avec des pertes de performance visibles.
- Il est possible de virtualiser un hyperviseur KVM lui-même dans un hyperviseur KVM physique. Cette pratique est appelée Nested virtualisation.
- Un module “/sys/module/kvm_intel/parameters/nested” doit être charger dans le noyau (au niveau de l’hôte physique).
- Par ailleurs, la machine virtuelle doit accéder directement aux instructions des CPUs physiques, ce qui nécessite d’activer la configuration “cpu host-passthrough” sur la machine virtuelle qui va elle-même remplir un rôle d’hyperviseur.
- Si la Nested Virtualization donne d’excellents résultats, on pourrait éprouver des faiblesses au niveau du stockage. Afin d’obtenir de meilleurs résultats dans l’exécution des machines virtuelles, on distinguera un espace de stockage natif (par exemple des espaces LVM ou NFS) pour héberger les disques des machines virtuelles de niveau 2. Disposer de disques rapides de type SSD est toujours un gain appréciable.
2.2. Création locale de modèles
On peut se référencer à cette documentation pour la construction des images : https://docs.openstack.org/image-guide/create-images-manually.html.
Pour déployer facilement des machines virtuelles, il est préférable de procéder à partir d’une image fraîchement installée (ou fabriquée par les soins d’un autre) que l’on clonera aisément.
Une première solution consiste donc à construire soi-même sa propre image, une seconde consiste à télécharger une image publique à laquelle on accorde sa confiance.
Sources : https://raw.githubusercontent.com/goffinet/virt-scripts/master/auto-install.sh et https://raw.githubusercontent.com/goffinet/virt-scripts/master/auto-install-tui.sh
Une installation native peut prendre un certain temps (quelques minutes à une heure) selon les capacité de l’hôte de virtualisation. Si le temps de formation est une denrée rare, il est préférable de télécharger des images déjà construites.
Pour les distributions standards Centos7, Debian 8 et Ubuntu 1604 on utilisera le script auto-install.sh :
./auto-install.sh
Centos 7, Debian Jessie or Ubuntu Xenial fully automatic installation by HTTP Repos and response file via local HTTP.
Usage : ./auto-install.sh [ centos | debian | ubuntu ] nom_de_vm
Please provide one distribution centos, debian, ubuntu and one guest name: exit
ou sa variante graphique auto-install-tui.sh (démo whiptail) :
┌─────────────┤ Virt-Scripts - Nom de la VM ├──────────────┐
│ Quel est le nom de la VM ? │
│ │
│ vm1_____________________________________________________ │
│ │
│ │
│ │
│ <Ok> <Annuler> │
│ │
└──────────────────────────────────────────────────────────┘
Ce script utilise les dépôts de paquets d’installation HTTP préconfigurés. Les variables sont à adapter dans le script lui-même. La configuration de l’installation est entièrement automatisée avec des fichiers Kickstart (Centos 7) ou preseed (Dedian 8 ou Ubuntu 1604) mis à disposition via le serveur Web local. Le modèle Debian/Ubuntu se termine par des commandes de “post-installation”. Cela peut donner des idées d’automation.
Le mot de passe root peut être trouvé facilement …
2.3. Téléchargement de modèles
On peut obtenir des images prêtes à l’emploi à partir d’au moins deux sources :
- Les images maison sont fabriquées par l’auteur et sont disponibles sur https://get.goffinet.org/kvm/ .
- Les images Openstack
1. Les images “maison”
Source : https://raw.githubusercontent.com/goffinet/virt-scripts/master/download-images.sh
Ces images “maison” sont fonctionnelles avec les scripts virt-scripts.
On les obtient facilement dans le dossier par défaut /var/lib/libvirt/images/ avec le script download-images.sh.
./download-images.sh
Please provide the image name :
debian7 debian8 centos7 ubuntu1604 metasploitable kali arch
Les images “debian8”, “centos7” et “ubuntu1604” ont été construites à partir des scripts d’auto-installation.
2. Les images OpenStack
Les images Openstack sont fonctionnelles avec l’outil kcli.
kcli host -h
--template [centos|fedora|debian|ubuntu|cirros]
Template/Image to download
--download Download Template/Image
Par exemple pour obtenir une image Openstack Centos 7 :
kcli host --download --template centos
Pour profiter pleinement des fonctionnalités de cloudinit (qui permet de lancer un script de configuration au moment du lancement de la machine virtuelle), il est conseillé de démarrer ces machines virtuelles avec une connectivité TCP/IP.
2.4. Déploiement des modèles
Je propose trois méthodes de déploiement :
- La première clone une machine machine virtuelle existante et optimise son disque.
- La seconde crée et lance une nouvelle machine virtuelle à partir d’une image modèle optimisée.
- La troisième avec
kcli(développé un peu plus bas).
1. Procédure de clonage
Source : https://raw.githubusercontent.com/goffinet/virt-scripts/master/clone.sh
Le script clone.sh se propose de cloner une machine virtuelle existante éteinte en optimisant son disque et en changeant son nom local (utile pour s’y retrouver immédiatement dans les consoles et la résolution de noms dynamique).
./clone.sh
This script clones, sparsifies and syspreps linux guest
Usage : './clone.sh <original guest> <destination guest>'
Please provide the guest name of a destroyed guest: exit
2. Copie d’une image modèle et définition d’une nouvelle machine virtuelle
Source : https://raw.githubusercontent.com/goffinet/virt-scripts/master/define-guest-image.sh
Le script d’installation define-guest-image.sh crée une machine virtuelle avec des paramètres par défaut à vérifier en variables à partir d’une copie d’une image modèle préparée.
./define-guest-image.sh
Usage : ./define-guest-image.sh <name> <image>
Le nom de l’image correspond au nom d’un disque qcow2 du même nom dans /var/lib/libvirt/images.
2.5. Gestion des machines virtuelles avec virsh
Avec libvirt et KVM, une “Machine Virtuelle (VM)” est appelée un “Domaine”.
Démarrage d’un domaine :
virsh start vm1
Arrêt d’un domaine :
virsh shutdown vm1
Extinction d’un domaine (comme on retire une prise de courant, il ne s’agit pas d’effacer le domaine) :
virsh destroy vm1
Pour retirer une VM (le ou les disques associés persistent) :
virsh undefine vm1
Pour retirer un domaine (et en effaçant ses disques) :
virsh undefine vm1 --remove-all-storage
Redémarrage d’un domaine :
virsh reboot vm1
Informations détaillées :
virsh dominfo vm1
Liste des domaines :
virsh list --all
Démarrage du domaine au démarrage de l’hôte :
virsh autostart vm1
Désactiver l’activation au démarrage :
virsh autostart vm1 --disable
Accéder à la console série (texte) du domaine :
virsh console vm1
Accéder à la console graphique du domaine :
virt-viewer vm1
2.6. Configuration des machines virtuelles
Ces différents script ne proposent pas vraiment de méthode profilage (voir plus bas avec kcli ou plus haut avec virt-scripts/define-guest-image.sh). Ils ont plutôt vocation à modifier “à la volée” ou “à chaud” des paramètres de dimensionnement en nombre de vcpus, en quantité de mémoire ou en ajout de disque.
Les manipulations sur le réseau sont vues dans le chapitre Services de passerelle.
1. Ajout de vcpus
./add-vcpu.sh
Description : This script set vcpus count
Usage : ./add-vcpu.sh <guest name> <size in MB>
Example : './add-vcpu.sh guest1 2' set 2 vcpus
2. Ajout de mémoire
./add-memory.sh
Description : This script set RAM in MB
Usage : ./add-memory.sh <guest name> <size in MB>
Example : './add-memory.sh guest1 1024' set RAM to 1024 MB
3. Ajout de disque
Ce script ajoute un disque par tranche de Go.
./add-storage.sh
Description : This script attach a disk to a live guest
Usage : ./add-storage.sh <guest name> <block device name> <size in GB>
Example : './add-storage.sh guest1 vdb 4' add a vdb 4GB disk to guest1
4. Ressources réseau
Les ressources réseau sont développées dans le chapitre Services de passerelle.
2.7. Déploiement avec kcli
D’abord, les commandes kcli :
kcli -h
Usage: kcli [OPTIONS] COMMAND [ARGS]...
Libvirt/VirtualBox wrapper on steroids. Check out
https://github.com/karmab/kcli!
Options:
--version Show the version and exit.
-h, --help Show this message and exit.
Commands:
bootstrap Handle hypervisor, reporting or bootstrapping...
clone Clone existing vm
console Vnc/Spice/Serial/Container console
container Create/Delete/List containers
create Deprecated command.
delete Delete vm/container
disk Add/Delete disk of vm
host List and Handle host
list List clients, profiles, templates, isos,...
network Create/Delete/List Network
nic Add/Delete nic of vm
plan Create/Delete/Stop/Start vms from plan file
pool Create/Delete pool
scp Scp into vm
ssh Ssh into vm
start Start vm/container
stop Stop vm/container
update Update ip, memory or numcpus
vm Create/Delete/Start/Stop/List vms
1. Profilage des machines virtuelles avec kcli
Le fichier ~/kcli_profiles.yml indique les profils disponibles à kcli sous forme de fichier yaml ((..) l’objet [d’un fichier yaml] est de représenter des informations plus élaborées que le simple CSV en gardant cependant une lisibilité presque comparable, et bien plus grande en tout cas que du XML, Wikipedia). Par exemple, le logiciel Ansible popularise ce format.
Le script generate-kcli-profiles.sh se propose de générer ce fichier de profils. (Source : https://raw.githubusercontent.com/goffinet/virt-scripts/master/generate-kcli-profiles.sh)
#!/bin/bash
#Please see https://github.com/karmab/kcli
file="/root/kcli_profiles.yml"
# check if kcli script is available
if [ -z $(which kcli) ] ; then echo "Please install kcli"; exit ; fi
# check if the profiles file exists
if [ -e ${file} ] ; then rm -i ${file} ; else echo "Exit"; exit ; fi
# Place the profiles file
cat << EOF > ${file}
xsmall:
template: CentOS-7-x86_64-GenericCloud.qcow2
numcpus: 1
memory: 256
nets:
- default
pool: default
cmds:
- echo testtest| passwd --stdin root
- yum -y install nmap
small:
template: CentOS-7-x86_64-GenericCloud.qcow2
numcpus: 1
memory: 512
nets:
- default
cmds:
- echo testtest| passwd --stdin root
- yum -y install nmap
medium:
template: CentOS-7-x86_64-GenericCloud.qcow2
numcpus: 1
memory: 1024
nets:
- default
disks:
- size: 16
cmds:
- echo testtest| passwd --stdin root
- yum -y install nmap
big:
template: CentOS-7-x86_64-GenericCloud.qcow2
numcpus: 2
memory: 2048
nets:
- default
disks:
- size: 32
cmds:
- echo testtest| passwd --stdin root
- yum -y install nmap
xbig:
template: CentOS-7-x86_64-GenericCloud.qcow2
numcpus: 2
memory: 3072
nets:
- default
disks:
- size: 32
cmds:
- echo testtest| passwd --stdin root
- yum -y install nmap
xxbig:
template: CentOS-7-x86_64-GenericCloud.qcow2
numcpus: 4
memory: 4096
nets:
- default
disks:
- size: 32
cmds:
- echo testtest| passwd --stdin root
- yum -y install nmap
EOF
La commande kcli list -p donne la liste des profils disponibles :
kcli list -p
Using local hypervisor as no kcli.yml was found...
+---------+
| Profile |
+---------+
| big |
| medium |
| small |
| xbig |
| xsmall |
| xxbig |
+---------+
2. Gestion des machines virtuelles avec kcli
Création d’une machine virtuelle sur base d’un profil :
kcli vm -p xsmall c1
Using local hypervisor as no kcli.yml was found...
Deploying vm c1 from profile xsmall...
c1 deployed!
On obtient ici la liste des machines virtuelles disponibles.
kcli list
Using local hypervisor as no kcli.yml was found...
+------------+--------+-----+------------------------------------+------------------+---------+
| Name | Status | Ips | Source | Description/Plan | Profile |
+------------+--------+-----+------------------------------------+------------------+---------+
| c1 | up | | CentOS-7-x86_64-GenericCloud.qcow2 | kvirt | xsmall |
| centos7 | down | | | | |
| debian8 | down | | | | |
| ubuntu1604 | down | | | | |
+------------+--------+-----+------------------------------------+------------------+---------+
Pour accéder à la console texte de la machine virtuelle :
kcli console -s c1
Arrêter la machine virtuelle :
kcli stop c1
Using local hypervisor as no kcli.yml was found...
Stopped vm c1...
c1 stopped!
Démarrer la machine virtuelle :
kcli start c1
Using local hypervisor as no kcli.yml was found...
Started vm c1...
c1 started!
Obtenir des informations sur la machine virtuelle :
kcli vm -i c1
Using local hypervisor as no kcli.yml was found...
name: c1
status: up
autostart: yes
description: kvirt
profile: xsmall
cpus: 1
memory: 256MB
net interfaces:eth0 mac: 52:54:00:b4:fa:7c net: default type: routed
ip: 192.168.122.175
diskname: vda disksize: 10GB diskformat: file type: qcow2 path: /var/lib/libvirt/images/c1_1.img
Destruction et effacement d’une machine virtuelle :
kcli delete c1
Using local hypervisor as no kcli.yml was found...
Do you want to continue? [y/N]: y
Deleted c1 vm...
Soyons curieux :
kcli vm -h
Using local hypervisor as no kcli.yml was found...
Usage: kcli vm [OPTIONS] [NAME]
Create/Delete/Start/Stop/List vms
Options:
-C, --client TEXT Use specific client
-p, --profile TEXT Profile to use
-l, --list List Vms
-i, --info Info about Vm
-f, --filters [up|down]
-s, --start Start Vm
-w, --stop Stop Vm
--ssh Ssh Vm
-1, --ip1 TEXT Optional Ip to assign to eth0. Netmask and gateway
will be retrieved from profile
-2, --ip2 TEXT Optional Ip to assign to eth1. Netmask and gateway
will be retrieved from profile
-3, --ip3 TEXT Optional Ip to assign to eth2. Netmask and gateway
will be retrieved from profile
-4, --ip4 TEXT Optional Ip to assign to eth3. Netmask and gateway
will be retrieved from profile
-5, --ip5 TEXT Optional Ip to assign to eth4. Netmask and gateway
will be retrieved from profile
-6, --ip6 TEXT Optional Ip to assign to eth5. Netmask and gateway
will be retrieved from profile
-7, --ip7 TEXT Optional Ip to assign to eth6. Netmask and gateway
will be retrieved from profile
-8, --ip8 TEXT Optional Ip to assign to eth8. Netmask and gateway
will be retrieved from profile
-L TEXT Local Forwarding
-R TEXT Remote Forwarding
-h, --help Show this message and exit.
Autres actions avec kcli :
- Se connecter en ssh sous le nom de la machine :
kcli ssh c1
- Ajouter un disque de 5Go à c1 en utilisant le pool default
kcli disk -s 5 -p default c1
- Effacer le 2e disque de c1
kcli disk -d -n c1_2.img c1
- Mise à jour à 1 Go de mémoire RAM (!)
kcli update -m 1024 c1
- Cloner c1 to new c2
kcli clone -b c1 c2
2.8. Stations graphiques
- LiveCD
- Image Docker
- X2Go
- image modèle
3. Automatisation des labs
3.1. Scripts bash
Pour créer des machines virtuelles à la volée selon un profil connectée à un réseau défini, on utilisera le script ./deploy-image-by-profile.sh (https://raw.githubusercontent.com/goffinet/virt-scripts/master/deploy-image-by-profile.sh) :
./deploy-image-by-profile.sh
Usage : ./deploy-image-by-profile.sh <name> <network_name> <profile> <image_name>
Profiles available : xsmall, small, medium, big, desktop
centos7 is the image name by default if ommited
Please download one of those images in /var/lib/libvirt/images :
https://get.goffinet.org/kvm/debian7.qcow2
https://get.goffinet.org/kvm/debian8.qcow2
https://get.goffinet.org/kvm/centos7.qcow2
https://get.goffinet.org/kvm/ubuntu1604.qcow2
https://get.goffinet.org/kvm/metasploitable.qcow2
https://get.goffinet.org/kvm/kali.qcow2
https://get.goffinet.org/kvm/arch.qcow2
Par exemple, pour déployer deux machines virtuelles avec profil “xsmall” “vm1” et “vm2” connectées au réseau “default”, l’image est celle par défaut (centos7) :
for x in vm1 vm2 ; do
./deploy-image-by-profile.sh $x default xsmall
done
Début d'installation...
Création du domaine... | 0 B 00:00
Création du domaine terminée. Vous pouvez redémarrer votre domaine en lançant :
virsh --connect qemu:///system start vm1
Time elapsed 10 second
Début d'installation...
Création du domaine... | 0 B 00:00
Création du domaine terminée. Vous pouvez redémarrer votre domaine en lançant :
virsh --connect qemu:///system start vm2
Time elapsed 11 second
3.2. “Plans” kcli
Un “plan” est la définition d’une topologie dans laquelle on peut placer :
- Des profils et leurs machines virtuelles à créer
- Les ressources réseau et stockage à créer
- L’intégration de Docker et Ansible
Avec le script generate-kcli-plan-sample.sh (https://raw.githubusercontent.com/goffinet/virt-scripts/master/generate-kcli-plan-sample.sh), on crée un fichier ./x.yml par exemple :
./generate-kcli-plan-sample.sh
rm: impossible de supprimer « x.yml »: Aucun fichier ou dossier de ce type
# Here is the content of the x.yml file :
lab-net-test:
type: network
cidr: 192.168.222.0/24
xs-test:
type: profile
template: CentOS-7-x86_64-GenericCloud.qcow2
memory: 256
numcpus: 1
disks:
- size: 8
nets:
- lab-net-test
machine1:
profile: xs-test
machine2:
profile: xs-test
machine3:
profile: xs-test
Un diagramme illustre le plan voulu :
Création d’un plan “plan-test” à partir de ce fichier ./x.yml :
kcli plan -f x.yml plan-test
Using local hypervisor as no kcli.yml was found...
Deploying Networks...
libvirt: Network Driver error : Network not found: no network with matching name 'lab-net-test'
Network lab-net-test deployed!
Deploying Vms...
machine1 deployed!
machine3 deployed!
machine2 deployed!
Liste des machines virtuelles :
kcli list
Using local hypervisor as no kcli.yml was found...
+------------+--------+-----------------+------------------------------------+------------------+---------+
| Name | Status | Ips | Source | Description/Plan | Profile |
+------------+--------+-----------------+------------------------------------+------------------+---------+
| c1 | up | 192.168.122.223 | CentOS-7-x86_64-GenericCloud.qcow2 | kvirt | xsmall |
| c2 | down | | | kvirt | xsmall |
| centos7 | down | | | | |
| debian8 | down | | | | |
| machine1 | up | 192.168.222.222 | CentOS-7-x86_64-GenericCloud.qcow2 | plan-test | xs-test |
| machine2 | up | 192.168.222.212 | CentOS-7-x86_64-GenericCloud.qcow2 | plan-test | xs-test |
| machine3 | up | 192.168.222.50 | CentOS-7-x86_64-GenericCloud.qcow2 | plan-test | xs-test |
| ubuntu1604 | down | | | | |
+------------+--------+-----------------+------------------------------------+------------------+---------+
Liste des réseaux :
kcli list -n
Using local hypervisor as no kcli.yml was found...
Listing Networks...
+--------------+---------+------------------+-------+----------+
| Name | Type | Cidr | Dhcp | Mode |
+--------------+---------+------------------+-------+----------+
| default | routed | 192.168.122.0/24 | True | nat |
| eth0 | bridged | 192.168.10.0/24 | N/A | N/A |
| lab-net-test | routed | 192.168.222.0/24 | True | nat |
| lan1 | routed | 192.168.1.0/24 | False | isolated |
+--------------+---------+------------------+-------+----------+
Lister les machines des plans :
kcli plan -l
Using local hypervisor as no kcli.yml was found...
+-----------+----------------------------+
| Name | Vms |
+-----------+----------------------------+
| | ubuntu1604,centos7,debian8 |
| kvirt | c2,c1 |
| plan-test | machine3,machine2,machine1 |
+-----------+----------------------------+
Destruction du plan “plan-test” :
kcli plan -d plan-test
Using local hypervisor as no kcli.yml was found...
Are you sure about deleting plan plan-test [y/N]: y
VM machine1 deleted!
VM machine2 deleted!
VM machine3 deleted!
Unused network lab-net-test deleted!
Plan plan-test deleted!
On trouvera des options “auto-start”, de démarrage, d’arrêt, de délai de démarrage entre machines virtuelles :
kcli plan -h
Using local hypervisor as no kcli.yml was found...
Usage: kcli plan [OPTIONS] [PLAN]
Create/Delete/Stop/Start vms from plan file
Options:
-C, --client TEXT Use specific client
-g, --get TEXT Download specific plan(s). Use --path for specific
directory
-p, --path TEXT Path where to download plans. Defaults to plan
-l, --list List Pools
-a, --autostart Set all vms from plan to autostart
-c, --container Handle container
-n, --noautostart Prevent all vms from plan to autostart
-f, --inputfile TEXT Input file
-s, --start start all vms from plan
-w, --stop
-d, --delete
-t, --delay INTEGER Delay between each vm's creation
-h, --help Show this message and exit.
Par exemple, ici un moyen de récupérer facilement des plans à partir d’un compte Github ou autre :
kcli plan --get kcli plan -g github.com/karmab/kcli/plans -p karmab_plans
