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. Services de passerelle

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

MachineRemarque
Les routeursRéseau : minimum 2 interfaces
Les serveursRessources adaptée en mémoire, vcpu et stockage
Les clients texteRessources minimale
Les clients graphiquesplus de mémoire
Les clients multimedia-
Les stations malveillantes (hacking)-

4. Profilage des machines virtuelles

Voici une proposition de profilage des machines virtuelles.

ProfilvCPUs (1)Mémoire RAM (2)Réseau (3)Stockage (4)
xsmall1256eth0 : default8 Go
small1512eth0 : default8 Go
medium11024eth0 : default16 Go
big22048eth0 : default32 Go
xbig23072eth0 : default32 Go
xxbig44096eth0 : default32 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