Vous souhaitez migrer vers KVM avec WebVirtMgr? Alors découvrez : kvm, libvirt, webvirtmgr, brctl et bien d'autres! Pré-requis : un serveur compatible KVM.
Sommaire
Cas d'usage concret
Vous voulez piloter votre migration vers KVM depuis une interface web plutôt qu'en ligne de commande : voici comment procéder avec WebVirtMgr.
Une migration tournée vers l’open-source
Afin d’assurer la pérennité et la stabilité dans mon infrastructure j’ai choisi KVM : standard ouvert, inter-opérable, aux fonctionnalitées immenses. Plus précisément, ce nouveau projet s’inscrit dans ma volonté d’être au plus proche de mon système Linux. KVM est présent dans les plus grands projets de cloud computing : openstack, opennebula, ovirt ainsi que bien d’autres.
En plus de KVM, il existe aussi ce fabuleux système de conteneur appelé docker, qui se base lui aussi intégralement sur Linux. Ils représentent à tous les deux de merveilleuses possibilités d’apprentissage pour comprendre le cloud. La gestion de KVM se fera en grande partie avec une interface en HTML5. Pour docker il existe Shipyard que je n’évoquerai pas dans l’article.
L’ensemble de mon article se base principalement sur le wiki de KVM, de WebVirtMgr ainsi que de libvirt.
La solution SaaS : WebVirtMgr
WebVirtMgr se présente sous la forme d’une interface web développée en bootstrap. Elle utilise l’API libvirt pour la gestion du ou des hyperviseurs, des réseaux, des interfaces, des stockages et des VM. L’accès à la VM se fera quant à elle via une console en VNC (novnc) ou html5 « spice ».
Plus d’informations sur : webvirtmgr.
Voici une illustration de mon infrastructure :
WebVirtMgr et l’hyperviseur KVM/QEMU
KVM (Kernel Virtual Machine) est un module du noyau Linux qui permet à un programme de l’espace utilisateur d’utiliser les fonctionnalités de virtualisation matérielle de différents processeurs. Aujourd’hui, il prend en charge les processeurs Intel récents et processeurs AMD (x86 et x86_64), PPC 440, PPC 970, S / 390, ARM (Cortex A15), et MIPS32 (emulation processeur).
QEMU peut faire usage de KVM lors de l’exécution d’une architecture cible qui est la même que l’architecture de l’hôte. Par exemple, lors de l’exécution qemu-system-x86 sur un processeur compatible x86, vous pouvez profiter de l’accélération de KVM – donnant vous bénéficiez pour votre accueil et votre système invité (émulation de machine virtuelle).
Source : http://wiki.qemu.org/KVM
Pré-requis avant l’installation
- Le processeur doit être compatible avec les technologies de virtualisation :
egrep '^flags.*(vmx|svm)' /proc/cpuinfo
Si un résultat apparaît alors votre processeur est opérationnel. Sinon c’est que votre processeur ne supporte pas la virtualisation.
Pas de panique ! Il existe webvirtmgr avec lxc et docker bien-entendu : découvrez-le !
- Installer les paquets suivants :
apt-get install kvm libvirt-bin bridge-utils sasl2-bin
- Télécharger le script de retspen et exécutez-le :
wget http://retspen.github.io/libvirt-bootstrap.sh
sh libvirt-bootstrap.sh
Pour information, à la fin du script vous deviez avoir les services suivants en fonctionnement :
- ok Starting system message bus: dbus.
- ok Starting libvirt management daemon: libvirtd.
Installation de WebVirtMgr
WebVirtMgr a besoin des paquets suivants pour fonctionner :
apt-get install git python-pip python-libvirt python-libxml2 novnc supervisor
Durant (la longue) installation, différentes questions feront leurs apparitions :
faut-il installer une base de données pour NOVA : oui
faut-il configurer la base de données de nova-common avec dbconfig-common : oui
type de serveur de base de données à utiliser avec nova-common ! sqlite3
La prochaine étape consiste à configurer python et l’environnement « django » :
mkdir /var/www
Déplacer vous dans le répertoire www :
cd /var/www
Télécharger le git de WebVirtMgr :
git clone git://github.com/retspen/webvirtmgr.git
Rendez-vous dans le répertoire suivant :
cd webvirtmgr
L’outil pip est utilisé car il installera rapidement et téléchargera automatiquement les dépendances nécessaires :
sudo pip install -r requirements.txt
Downloading/unpacking django==1.5.5 (from -r requirements.txt (line 1))
Downloading Django-1.5.5.tar.gz (8.1MB): 8.1MB downloaded
Running setup.py (path:/tmp/pip_build_root/django/setup.py) egg_info for package django
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
Downloading/unpacking gunicorn==18.0 (from -r requirements.txt (line 2))
Downloading gunicorn-18.0.tar.gz (366kB): 366kB downloaded
Running setup.py (path:/tmp/pip_build_root/gunicorn/setup.py) egg_info for package gunicorn
warning: no previously-included files matching '*.pyc' found under directory 'docs'
warning: no previously-included files matching '*.pyo' found under directory 'docs'
warning: no previously-included files matching '*.pyc' found under directory 'tests'
warning: no previously-included files matching '*.pyo' found under directory 'tests'
warning: no previously-included files matching '*.pyc' found under directory 'examples'
warning: no previously-included files matching '*.pyo' found under directory 'examples'
Downloading/unpacking lockfile>=0.9 (from -r requirements.txt (line 5))
Downloading lockfile-0.10.2-py2-none-any.whl
Installing collected packages: django, gunicorn, lockfile
Running setup.py install for django
changing mode of build/scripts-2.7/django-admin.py from 644 to 755
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
changing mode of /usr/local/bin/django-admin.py to 755
Running setup.py install for gunicorn
warning: no previously-included files matching '*.pyc' found under directory 'docs'
warning: no previously-included files matching '*.pyo' found under directory 'docs'
warning: no previously-included files matching '*.pyc' found under directory 'tests'
warning: no previously-included files matching '*.pyo' found under directory 'tests'
warning: no previously-included files matching '*.pyc' found under directory 'examples'
warning: no previously-included files matching '*.pyo' found under directory 'examples'
Installing gunicorn_paster script to /usr/local/bin
Installing gunicorn script to /usr/local/bin
Installing gunicorn_django script to /usr/local/bin
Found existing installation: lockfile 0.8
Uninstalling lockfile:
Successfully uninstalled lockfile
Successfully installed django gunicorn lockfile
Cleaning up...
Lancer la création de la base de données via django :
./manage.py syncdb
WARNING:root:No local_settings file found.
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_groups
Creating table auth_user_user_permissions
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table servers_compute
Creating table instance_instance
Creating table create_flavor
You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Please enter either "yes" or "no": yes
Please enter either "yes" or "no": yes
Username (leave blank to use 'root'): kassianoff
Email address: [email protected]
Password:
Password (again):
Superuser created successfully.
Installing custom SQL ...
Installing indexes ...
Installed 6 object(s) from 1 fixture(s)
On recommence avec cette fois-ci collectstatic :
./manage.py collectstatic
Type 'yes' to continue, or 'no' to cancel: yes
75 static files copied
Donner les droits au serveur web dans le répertoire de WebVirtMgr :
chown -R www-data:www-data /var/www/webvirtmgr/
Modification du script et du lancement de VNC :
sudo service novnc stop
[ ok ] Stopping OpenStack NoVNC proxy: nova-novncproxy.
Suppression du script au lancement de notre distribution debian :
update-rc.d -f novnc remove
update-rc.d: using dependency based boot sequencing
Suppression du script dans init.d :
rm /etc/init.d/novnc
Renseigner des paramètres de lancement dans le fichier webvirtmgr.conf :
nano /etc/supervisor/conf.d/webvirtmgr.conf
[program:webvirtmgr]
command=/usr/bin/python /var/www/webvirtmgr/manage.py run_gunicorn -c /var/www/webvirtmgr/conf/gunicorn.conf.py
directory=/var/www/webvirtmgr
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/webvirtmgr.log
redirect_stderr=true
user=www-data
program:webvirtmgr-console
command=/usr/bin/python /var/www/webvirtmgr/console/webvirtmgr-console directory=/var/www/webvirtmgr autostart=true autorestart=true stdout_logfile=/var/log/supervisor/webvirtmgr-console.log redirect_stderr=true user=www-data
On arrête le service supervisor et on le démarre :
service supervisor stop
service supervisor start
L’installation est terminée et nous pouvons désormais accéder à l’interface WebVirtMgr via le port 8000 de notre machine.
Le tunneling SSH sous linux
La méthode du tunnelling SSH permet la redirection des ports 8000 et 6080 (novnc) vers notre poste client (sécurisé) :
ssh [email protected]:port -L localhost:8000:localhost:8000 -L localhost:6080:localhost:6080
Rendez-vous sur l’url : localhost:8000 et rentrer vos identifiants de connexion configurés lors du ./manage.py syncdb :
Connexion entre WebVirtMgr et KVM/QEMU
Plusieurs étapes seront nécessaire avant de pouvoir configurer l’infrastructure.
- Créer vos identifiants de connexion TCP comme ceci :
saslpasswd2 -a libvirt kassianoff.fr
Password:
Again (for verification):
- Déclarer votre hyperviseur dans virsh :
virsh -c qemu+tcp://localhost/system nodeinfo
Please enter your authentication name: kassianoff.fr
Please enter your password:
CPU model: x86_64
CPU(s): 8
CPU frequency: 1632 MHz
CPU socket(s): 1
Core(s) per socket: 4
Thread(s) per core: 2
NUMA cell(s): 1
Memory size: 32917020 KiB
Désormais ajoutons notre connexion TCP en cliquant sur le bouton : « Add connection »
Le résultat est le suivant :
Prise en main de la solution WebVirtMgr
Il me semble important de comprendre les différentes rubriques qui composent WebirtMgr :
- Instances : Gestion et création de machines virtuelles, ce sont nos instances.
- Storages : Gestion et création des différents pools de stockage (repertoire, iso, nfs, lvm…).
- Networks : Gestion et création des réseaux (bridge, route, nat…).
- Interfaces : Gestion et création des différentes interfaces que peuvent utiliser les réseaux.
- Secrets : Je n’ai pas eu d’informations la concernant, si un visiteur a des informations je suis preneur !
- Overview : Superviser l’ensemble de notre infrastructure : ressouces utilisées (cpu, mémoire etc…).
J’ai utilisé toutes les rubriques (excepté Secrets), commencez par suivre les étapes ci-dessous pouvoir créer une instance.
Création des pools de stockage
Avant de démarrer la création d’une machine, nous aurons besoin de pools de stockage, cliquez sur Storages puis sur New storages la configuration est la suivante :
Création d’un repertoire DIR avec le chemin /var/lib/libvirt/images.
Création du répertoire ISO avec le chemin /var/www/webvirtmgr/images :
Sur un OVH dédié, utilisez NFS-common, et créez un répertoire nfs pour le connecter au NFS backup storage
apt-get install nfs-common
mkdir /var/lib/libvirt/nfs/
mount -t nfs ftpback-rbxX-XXX.ovh.net:/export/ftpbackup/nsXXXXXXX.ovh.net /var/lib/libvirt/nfs/
Dans la création du poo » il existe le mode NETFS compatible avec NFS, cependant le format n’est pas pris en compte.
La solution consiste à utiliser le mode dir en spécifiant le répertoire nfs précédemment monté :
Vérifiez vos différents pools de storage dit : nfs, iso, images :
Je ne vais pas évoquer la création d’une machine dans le menu images ni même l’ajout d’un fichier ISO via WebVirtMgr.
La raison est simple, j’utilise le terminal pour ces tâches là. Concentrons-nous sur les réseaux avant de créer notre VM.
La rubriques networks dans WebVirtMgr
L’ajout de réseaux se fait via l’onglet networks. Ajoutez deux réseaux bridge lbr0 et lbr1 :
Reproduisez la manipulation ci-dessus pour créer la seconde interface bridge, ce qui donnera :
Interfaces et réseaux bridgés sous linux
La rubrique interfaces affiche le fichier de configuration /etc/networks/interface on y retrouvera lo,br0, lbr0, lbr1.
Mais avant de configuer nos interfaces bridge, voyons la configuration actuelle :
ifconfig
eth0 Link encap:Ethernet HWaddr 08:60:6e:e5:bd:47
inet adr:XX.XXX.XXX.XXXX Bcast:XX.XXX.XXX.XXX Masque:255.255.255.0
adr inet6: XXXX:XXXX:X:XXXX::/xx Scope:Global
adr inet6: XXXX::XXX:XXXX:XXXX:XXXX/xx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:2243 erreurs:0 :0 overruns:0 frame:0
TX packets:1618 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:490019 (490.0 KB) Octets transmis:243883 (243.8 KB)
lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:65536 Metric:1
Packets reçus:140 erreurs:0 :0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:22966 (22.9 KB) Octets transmis:22966 (22.9 KB)
virbr0 Link encap:Ethernet HWaddr 22:e2:0b:e7:c2:d1
inet adr:192.168.122.1 Bcast:192.168.122.255 Masque:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
On remarque la configuration suivante : l’interface eth0 qui représente l’adresse IP publique du serveur, l’interface loopback (logique) ainsi que l’interface virbr0 qui est créée automatiquement en mode NAT.
Dans la mise en place de mon infrastructure, le réseau à une place importante. J’ai donc créé trois interfaces :
- br0 = bridgé vers l’interface principale eth0 de mon hôte debian (utilisé pour mes IPO failover OVH).
- lbr1 = une interface bridge utilisée par VyOS pour mes services web.
- lbr2 = une interface bridge utiliser par VyOS pour mes dockers et VM avec possibilité d’inter-connexions docker/kvm.
Mon routeur/pare-feu manage mes différentes interfaces br0, lbr1, lbr2. Voici un schéma d’illustration :
Commençons par configurer l’interface br0 : (Wiki de debian)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
address XX.XXX.XXX.XXX
netmask 255.255.255.0
network XX.XXX.XXX.0
broadcast XX.XXX.XXX.255
gateway XX.XXX.XXX.254
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
iface eth0 inet6 static
address XXXX:XXXX:X:XXXX::
netmask 64
post-up /sbin/ip -family inet6 route add XXXX:XXXX:X:XXXX:XX:XX:XX:XX dev eth0
post-up /sbin/ip -family inet6 route add default via XXXX:XXXX:X:XXXX:XX:XX:XX:XX
pre-down /sbin/ip -family inet6 route del default via XXXX:XXXX:X:XXXX:XX:XX:XX:XX
pre-down /sbin/ip -family inet6 route del XXXX:XXXX:X:XXXX:XX:XX:XX:XX dev eth0
Redémarrer l’interface (la connexion en SSH avec votre serveur ne devrait pas être interrompue) :
/etc/init.d/network restart
Vérifier la configuration de l’interface bridge sur l’hôte :
ifconfig br0
br0 Link encap:Ethernet HWaddr 08:60:6e:e5:bd:47
inet adr:XX.XXX.XXX.XXX Bcast:XX.XXX.XXX.255 Masque:255.255.255.0
adr inet6: XXXX::XXX:XXXX:XXXX:XXXX/xx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2344432 errors:0 dropped:0 overruns:0 frame:0
TX packets:1599970 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:9383508945 (8.7 GiB) TX bytes:312106046 (297.6 MiB)
La commande pour visualiser l’interface bridgée :
btctl show
br0 8000.08606ee5bd47 no eth0
Le paquet bridge nous offre la possibilité de créer directement nos interfaces telles que :
brctl addbr lbr0
brctl addbr lbr1
Ensuite, il nous faut démarrer les interfaces bridgées lbr0 et lbr1 :
ip link set dev lbr0 up
ip link set dev lbr1 up
Cependant, la méthode de libvirt ne rend pas permanente nos interfaces ! Ajoutez les deux interfaces de façon définitive :
nano /etc/network/interface
auto lbr0
iface lbr0 inet manual
bridge_ports none
bridge_stp off
auto lbr1
iface lbr1 inet manual
bridge_ports none
bridge_stp off
/etc/init.d/network restart
brctl show
br0 8000.08606ee5bd47 no eth0
lbr0 8000.fe5400047801 no
lbr1 8000.fe54000a522b no
virbr0 8000.000000000000 yes
Le serveur hôte peut redémarrer sans crainte de perdre sa configuration désormais. Voici les différentes interfaces bridgées :
Vous avez la possibilité de désactiver l’interface au démarrage :
virsh net-autostart --disable default
Ou encore de supprimer définitivement l’interface default :
virsh net-destroy default
Création d’une instance dans WebVirtMgr
Dans la rubrique instances, cliquez sur le bouton New Instance et plusieurs possibilités s’offre à vous.
- Instance personnalisée, Template ou fichier de configuration XML.
Ci-dessous on retrouve aussi des templates pré-définis et numérotés de 1 à 6 qui permettent de créer une image.
Dans ce cas précis, je vais utiliser une instance personnalisée. Mais avant il faudra créer un disque pour la VM.
Comme expliqué précédemment je préfère utiliser le mode cli pour créer le disque de ma future machine :
qemu-img create -f qcow2 vdisk 10G
Pour ceux qui souhaite convertir une machine VMware vers KVM :
qemu-img convert vm1-flat.vmdk -O qcow2 vm1
Afficher des informations concernant notre machine :
qemu-img info vdisk
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 136K
cluster_size: 65536
Utiliser maintenant le HDD vdisk pour créer une VM vdisk :
Lancer la création en cliquant sur le bouton create : la gestion de la machine « vdisk » apparaît avec ses options :
A ce moment précis, libre à vous de découvrir les rubriques ci-dessus mais n’oubliez pas :
- « Access » pour sélectionner votre type de console, puis modifié la disposition du clavier (si mode : novnc).
- « Settings » pour l’ajout d’un Media ISO à la machine virtuelle.
- Dans « Settings » éditer la configuration du xml de la machine vdisk. Uniquement si vous souhaitez attribuer une Failover OVH à votre VM. La partie interfaces de la machine doit contenir (exemple sur mon routeur/pare-feu) :bash
<interface type='bridge'> <mac address='xx:xx:xx:xx:xx:xx'/> <source bridge='br0'/> <target dev='vnet0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> - Lancement de la machine : Power puis Start, l’accès à la console ce fera via Accès/Console
- Une pop-up s’ouvre avec novnc et l’accès à la VM :
C’est terminé, vous êtes désormais prêt à utiliser les ressources de votre infrastructure et votre VM !
Mais avant sauvegardez à chaud votre VM.
Sauvegarder vos machines KVM à chaud
La sauvegarde peut se faire par clone via l’interface webvirtmgr ou encore via un simple cp : (vers NFS)
cp /var/lib/libvirt/images/vdisk /var/lib/libvirt/nfs/vdisk.02.03.2015
Vue d’ensemble de l’infrastructure
La charge d’utilisation de l’infrastructure est disponible dans la rubrique overview ce qui permet d’obtenir une vue d’ensemble en temps réel. Voici l’utilisation de mon infrastructure webvirt-kassianoff une fois en place :
Mise à jour de WebVirtMgr
Les mise à jours technologiques et de sécurité sont bien entendu très importantes, pour cela rien de plus simple :
Rendez-vous dans le répertoire de WebVirtMgr :
cd /var/www/webvirtmgr
Puis lancez les commandes suivantes :
remote: Counting objects: 27, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 27 (delta 7), reused 6 (delta 6), pack-reused 7
Unpacking objects: 100% (27/27), done.
From git://github.com/retspen/webvirtmgr
ed176e4..c875e0d master -> origin/master
Updating ed176e4..c875e0d
Fast-forward
console/views.py | 3 ++-
create/views.py | 7 ++++---
hostdetail/views.py | 5 +++--
instance/views.py | 15 ++++++++-------
interfaces/views.py | 7 ++++---
networks/views.py | 9 +++++----
secrets/views.py | 3 ++-
servers/views.py | 9 +++++----
storages/views.py | 9 +++++----
templates/base.html | 2 +-
templates/base_auth.html | 2 +-
templates/login.html | 2 +-
12 files changed, 41 insertions(+), 32 deletions(-)
./manage.py collectstatic
WARNING:root:No local_settings file found.
You have requested to collect static files at the destination
location as specified in your settings.
This will overwrite existing files!
Are you sure you want to do this?
Type 'yes' to continue, or 'no' to cancel: yes
0 static files copied, 75 unmodified.
service supervisor stop
Je termine ma migration et j’espère que votre nouvelle infrastructure vous plaît !
Conclusion
Cet article a présenté la mise en place d’une infrastructure de virtualisation KVM/QEMU pilotée par l’interface web WebVirtMgr : installation des paquets nécessaires, configuration des pools de stockage, des réseaux et interfaces bridgées, puis création et sauvegarde d’une instance. Cette solution open-source et interopérable permet de gérer facilement un hyperviseur KVM sans dépendre d’un éditeur propriétaire, tout en conservant la souplesse du terminal Linux pour les tâches les plus techniques. J’espère que cette nouvelle infrastructure, plus proche de mes habitudes Linux, continuera de bien fonctionner dans la durée.