Notes et astuces sur les systèmes libres basés sur GNU/Linux

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - virtualisation

Fil des billets

lundi, 19 août 2013

Netkit, UML et Qemu sont dans un bateau Archlinux ... qui tombent à l'eau ?

Hi,

Boussole
Cet article est un résumé de mon expérience de la veille, cela me permettra de savoir ce que j'ai testé et ce qui n'a pas fonctionné mais j'espère que cela vous fera découvrir des solutions.
Un article riche en lien et en expérience, j'espère que cela vous sera utile.

Le besoin :

Comme vous le savez maintenant, je suis en train de configurer mon serveur dedié Online aux petits ognons (nouveaux).
Pour ce faire, je me suis monté une petite infrastructure passionnante.
Pour être un peu plus proche de ma configuration réelle, je m'étais dit qu'il me fallait un système qui me permettrait de simuler mes Iptables et le contexte réseau autour de mon serveur.
J'avais pensé utiliser Virtualbox ou kvm mais la procédure d'installation me paraissait longue et lourde (installation de l'hyperviseur, génération d'un fichier disque dur, installation de l'os virtualisé sur le disque dur) pour un si petit besoin. ...
Par pur fainéantise et commodité, je souhaitais un logiciel prêt à l'emploi.

Netkit : Une solution clé en main intéressante pour simuler des labos virtuels

Netkit était idéal car je n'avais qu'à installer, indiquer le nombre de VM et lancer la vm.
Si vous ne connaissez pas ce projet, je vous invite à consulter les ressources en-dessous pour vous faire une petite idée.
Je dégaine mon yaourt. Un paquet existe. Je lance la compile ...
Crack pas assez de place dans tmp... Faudra que je me penche sur ce problème déjà rencontré, mais je pare au plus pressé, je change de cheval.

UML (UserMode Linux) : Un trousse à outil pour virtualiser une machine

Je prends l’élément de base de netkit, je tombe sur UML.
Wikipedia me dit que c'est nul mais je lis quelques articles et cela semble prometteur et customisable.
Je compile le paquet, je télécharge tout comme il faut, paf ça ne marche pas, cela boucle au démarrage, j'ai dû louper une étape.

QEMU :

Le temps file et les solutions défilent, je vais donc revenir aux vrais valeurs, je réinstalle vite fait un kvm-qemu.
Le paquet a changé de nom depuis mon dernier article, je vais donc feuilleter le wiki fr Archlinux mais il n'est pas à jour.
Peut être que les paquets évoluent trop vite pour notre wiki francophone ...
Il faudra que je m'inscrive pour modifier le wiki.

Comme dit plus haut, je ne voulais pas me farcir l'installation d'un OS juste pour une VM, je pensais donc réutiliser l'image disque Debian téléchargée sur le site UML..
L'image disque n'est plus bootable, je télécharge le kernel mais cela ne marche pas mieux, décidément je suis maudit, je n'ai pas envie de chercher plus longtemps.

Le renoncement ...

On revient à la base de la base, je télécharge une image netinst de Debian et je suis parti.
Tout marche comme il faut, out of box.
Youpii, enfin.
Un petit bémol, la solution "réseau privé" fournie par Qemu ne me convient pas car la machine n'est pas dans le même réseau que ma machine réelle, je devrais donc utiliser des redirections pour tester mon firewall.
Or, quand je teste des règles de pare-feu, il vaut mieux avoir une architecture simple sans redirection foireuse par dessus.
Dans mon optique de réutilisation et de gain de temps, qui a été une pure réussite jusqu'à présent, j'essaye de créer une interface virtuelle et de l'ajouter à mon pont à la mode lxc.
Après quelques incompréhensions, je tombe sur l'explication de lxc sur le réseau veth..
Je me dis qu'il faut juste prendre le numéro de process de mon kvm pour que cela fonctionne mais non cela aurait été trop simple, cela ne fonctionne pas.
J'essaye la solution simple du Wiki archlinuxfr : la création d'une interface virtuelle.
Bien entendu, le paquet uml_utilities a disparu ce qui n'arrange pas mes affaires.
Je me rabats sur la solution openvpn mais je l'abandonne car je peux utiliser la fonction dédiée dans Iproutes2.
Il faudra vraiment que je m'inscrive pour apporter ma pierre à l'édifice Wiki Archlinux.

La partie utile :

#Installation de Qemu
yaourt -S qemu
#Creation du disque dur
qemu-img create debian.raw -f raw 4G
#Installation de l'os virtuel sur le disque virtuel
qemu-system-x86_64 -enable-kvm -m 512 -k fr -drive file=debian.raw,if=virtio,media=disk -usb -usbdevice tablet -cdrom votre_iso.iso -boot d
#Creation de l'interface virtuel
sudo ip tuntap add dev tap1 mode tap
#On monte l'interface
sudo ip link set tap1 up

On l'ajoute au pont (pré-requis la configuration du pont cf : mon article lxc)

brctl addif br0 tun1
#On boot sur le système tout beau :
qemu-system-x86_64 -enable-kvm -m 512 -k fr -drive file=debian-7-amd64.raw,if=virtio,media=disk -usb -usbdevice tablet -net nic -net tap,ifname=tap1,script=no --curses

L'option : curses permet de ne pas ouvrir une nouvelle fenêtre et de n'afficher qu'une fenêtre console, cela permet d'économiser des ressources.
Pour ceux qui ne veulent pas du tout de sortie console, il y a l'option nographic.

Et voilà, plus le temps manque plus on en perds à chercher quelque chose qui fonctionne.
J'arriverai même à penser qu'avoir une distribution rolling release n'est peut être pas l'idéal pour la documentation de la communauté.

                           Au plaisir !!!

Ressources :

Netkit : Un pdf intérressant , Quelques exemples à picorer
UML : Tutoriel pas à pas UML Utilisation d'UML pour monter des labos Le wiki d'Ubuntu
Qemu : Présentation détaillée de Qemu dans un contexte pédagogique L'architecture réseau de Qemu

jeudi, 16 mai 2013

LXC, la solution de virtualisation légère

Si comme moi vous aimez bien tester différents outils ou services GNU/Linux sans encombrer votre machine réelle, la solution de virtualisation par container LXC pourrait grandement vous aider.poupée russe

Voici les quelques avantages de cet outil :

  • Optimisation de l'utilisation de votre machine en hébergeant plusieurs configurations systèmes
  • Sécurisation de vos process en les mettant à l'abris dans un "chroot amélioré".
  • Facilité d'installation car l'outil est intégré au noyau Linux.
  • Avoir sous la main un autre GNU/Linux sans manger toute vos ressources CPU


Cet article n'a pas d'autre prétention que de me servir de bloc-note lors d'une prochaine réinstallation et ajouter une ressource française sur le sujet.

Pour l'installer sous Debian :Logo debian

Si besoin ajouter le système de paramétrage CGROUP à votre liste de points de montage dans votre fichier etc/fstab (vérifiez si la ligne suivante est déjà présente):

cgroup          /sys/fs/cgroup  cgroup  defaults        0       0

Si l'on souhaite mettre nos machines virtuelles directement sur le réseau physique, nous avons besoin de créer un pont sur lequel viendra se brancher notre machine physique ainsi que nos machines virtuelles.

Le paquet bridge-utils va créer un pont/commutateur/switch entre vos machines virtuelles/physique et votre réseau local (LAN).

Schema reseau

aptitude install bridge-utils
Pour mettre en place cette configuration, vous allez devoir remplacer votre eth0 en DHCP par br0 dans /etc/network/interfaces :
auto br0
iface br0 inet dhcp
bridge-ports eth0

Installez le paquet LXC contenant un ensemble de script et de templates :

aptitude install lxc

Si vous souhaitez installer une Debian dans un de vos conteneurs, vous aurez besoin d'installer debootstrap :

aptitude install debootstrap

Maintenant, pour créer votre premier container de type Debian sans limitation :

lxc-create -n le_nom_de_votre_container -t debian

Il faudra configurer votre container avant de le lancer en allant toucher le fichier de configuration dans /var/lib/le_nom_de_votre_container/config. Les lignes importantes à modifier sont :

lxc.network.type = veth
lxc.network.flags = up
#On s'appuie sur l'interface br0 physique
lxc.network.link = br0
#On nomme notre interface virtuel eth0
lxc.network.name = eth0

Par défaut sous Debian, lxc ne vous crée pas de terminal pour vous connecter à votre machine virtuelle.
Avouez que c'est dommage !
Nous allons y remédier en créant nous même le fichier spécial correspondant à un terminal virtuel avec mknod :

mknod -m 666 /var/lib/lxc/le_nom_de_votre_container/roots/dev/tty c 4 1

Si vous souhaitez lancer votre machine avec une console virtuel mais ATTENTION vous ne pourrez pas quitter la console sans éteindre votre container :
lxc-start -n le_nom_de_votre_container

Si vous voulez avoir en tâche de fond votre machine virtuelle ou tout simplement pouvoir quitter votre console quand vous le souhaitez (via Ctrl a +q) :

lxc-start -n le_nom_de_votre_container -d

Maintenant, vous pouvez accéder à votre console :

lxc-console -n le_nom_de_votre_container

Ma difficulté à l'installation venait surtout de la création de la console virtuelle sur une version Testing.

Pour l'installer sous ArchLinux :Logo archlinux

La seule difficulté que j'ai rencontré sous Archlinux est la configuration du bridge.
Je passe brièvement l'installation des paquets vus précédemment :

pacman -S lxc bridge-utils

Si besoin rebooter votre machine pour prendre en compte vos nouveaux modules :

lsmod | grep br
bridge                 85984  0
stp                     1621  1 bridge
llc                     3729  2 stp,bridge

Normalement, l'utilitaire netcfg doit créer votre pont automatiquement avec les paramètres que l'on va spécifier ci-dessous :

pacman -S netcfg
Modifier le fichier/etc/network.d/bridge :
INTERFACE="br0"
CONNECTION="bridge"
DESCRIPTION="Mon pont davignon"
BRIDGE_INTERFACES="enp4s0"
IP="dhcp"

Modifier le fichier /etc/conf.d/netcfg :

# Network profiles are found in /etc/network.d
NETWORKS=(bridge)

Ajouter l'unité à votre démarrage afin de monter le réseau à chaque démarrage :

systemctl enable netcfg@bridge.service

Pour créer manuellement votre pont si cela n'a pas été fait :

brctl addif br0 enp4s0

Modifier le fichier /usr/share/lxc/templates/lxc-debian (L.175)afin de faire fonctionner le template:

arch="amd64"


Au plaisir.

Ps : Pas de bol pour moi, une personne vient de publier un article sur LXC sous Debian à l'instant en Français. J'aurais été en début d'écriture, je n'aurai pas écrit ...

Edit : Ajout de la modification du template debian

samedi, 17 mars 2012

Installation de QEMU/KVM geré par Libvirt sous Archlinux

Bonjour,
virtualisation

Un petit billet pour coucher sur l'écran la procédure d'installation de QEMU-KVM allié à une GUI virt-manager sous ArchLinux.

QEMU est un logiciel de virtualisation fonctionnant sous GNU/Linux qui permet d'émuler un ou plusieurs systèmes d'exploitations sur votre ordinateur hôte.

KVM est un fork de QEMU apportant le support du module KVM qui améliore sensiblement la vitesse de virtualisation. Même si dans cet article, nous allons utiliser à proprement parler le logiciel KVM, j'utiliserai quand même l’appellation QEMU/KVM.

D'abord, une petite vérification de la capacité de votre processeur à utiliser correctement le module KVM :

egrep '^flags.*(vmx|svm)' /proc/cpuinfo >/dev/null && echo OK || echo KO

Si vous avez OK, vous pouvez passer aux étapes suivantes, sinon il faudra vous contenter de QEMU tout seul.

Voici les paquets dont nous avons besoin et leur intérêts :

  • qemu-kvm : le logiciel qui va vous permettre d'émuler vos machines.
  • virt-manager : une GUI pour gérer vos machines virtuelles.
  • dnsmasq : Forwader DNS et serveur DHCP léger, indispensable pour fournir du réseau à vos machines émulées.
  • virtinst : CLI permettant de gérer le provisionning des machines virtuels.
  • libvirt : API pour dialoguer avec vos machines virtuelles (openvz,kvm,qemu,virtualbox,xen,etc..)

Maintenant, il suffit de les installer avec votre gestionnaire de paquet favoris :

yaourt -Sy qemu-kvm virt-manager dnsmasq virtinst libvirt

Afin de pouvoir utiliser notre application en tant qu'utilisateur, il est necessaire de vous mettre dans le groupe KVM :

sudo usermod martin -aG kvm

Pour ceux qui ont la chance de supporter le module KVM (cf ligne de commande plus haut), il est temps de le charger :

sudo modprobe -v kvm

Et selon la marque de votre processeur de charger également l'un des deux modules suivants :

sudo modprobe -v kvm_intel
sudo modprobe -v kvm_amd

Ensuite, il est necessaire de lancer le daemon vous permettant de communiquer avec vos machines virtuelles :

sudo /etc/rc.d/libvirtd start

Les paramétrages précédents ne sont valables que pour la session en cours. Aussi, pour éviter ces manipulations à chaque utilisation de votre solution de virtualisation, je vous conseille de modifier le rc.conf :

sudo nano /etc/rc.conf :
MODULES=(kvm kvm_amd ...)
DAEMONS=(libvirtd ...)

Ensuite, il vous suffit de lancer la commande pour pouvoir bénéficier de votre travail:

virt-manager

Pour plus d'information sur l'utilisation de l'outil en lui-même, je vous renvoie vers ce billet très complet de NicoLargo.

A tantôt tout le monde !