VIMINAL TP vodka (Virtualization Operation Discovery on KVM Architecture)

(Virtualization Operation Discovery on KVM Architecture) TELECOM Lille 1 J. Landru 1 / 39 V1.1-20120221

Préambule : L'ensemble des contenus relatif à ce sujet de TP est publié sous licence Creative-Commons CC-BY-NC-SA. Merci à Messieurs Luc Betry et Tovoherizo Rakotonavalona pour leur relecture attentive et leurs observations. Jacques Landru Ingénieur d'etudes - Institut TELECOM TELECOM Lille1 Dept Informatique et Réseaux. TELECOM Lille 1 J. Landru 3 / 39 V1.1-20120221

Licence Creative Commons CC-BY-NC-SA Paternité-Pas d'utilisation Commerciale-Partage des Conditions Initiales à l'identique 2.0 France Vous êtes libres : de reproduire, distribuer et communiquer cette création au public de modifier cette création... Selon les conditions suivantes : Paternité. Vous devez citer le nom de l'auteur original de la manière indiquée par l'auteur de l'oeuvre ou le titulaire des droits qui vous confère cette autorisation (mais pas d'une manière qui suggérerait qu'ils vous soutiennent ou approuvent votre utilisation de l'oeuvre). Pas d'utilisation Commerciale. Vous n'avez pas le droit d'utiliser cette création à des fins commerciales. Partage des Conditions Initiales à l'identique. Si vous modifiez, transformez ou adaptez cette création, vous n'avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci. A chaque réutilisation ou distribution de cette création, vous devez faire apparaître clairement au public les conditions contractuelles de sa mise à disposition. La meilleure manière de les indiquer est un lien vers cette page web. Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits sur cette oeuvre. Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs. Les informations détaillées sont disponibles aux URL suivantes : http://fr.creativecommons.org/index.htm http://creativecommons.org/licenses/by-nc-sa/2.0/fr/ http://fr.wikipedia.org/wiki/licence_creative_commons TELECOM Lille 1 J. Landru 5 / 39 V1.1-20120221

Table des matières 1 ) Contexte du TP...9 2 ) Eco-système de l'environnement KVM...9 2.1 ) Votre première machine virtuelle avec KVM...11 2.2 ) Installation d'un système dans la machine virtuelle...12 2.3 ) «Faisons les clones»...15 2.4 ) Connexion au réseau...19 2.4.a ) Connectivité des VM...19 Mise en oeuvre du mode «ponté»...20 2.5 ) La boite à outils libvirt...23 2.5.a ) Création d'une machine virtuelle avec libvirt...24 2.5.b ) Contrôle de la machine virtuelle avec virsh...25 2.6 ) Virt-manager le gestionnaire de machines virtuelles...27 TELECOM Lille 1 J. Landru 7 / 39 V1.1-20120221

TP VODKA (Virtualization Operation Discovery on KVM Architecture ) 1 ) Contexte du TP Ce TP virtualisation est bâti sur la plate-forme VIMINAL (VIrtual Model for Ip Network Architecture Lab). L'objectif est de vous familiariser avec les éléments de base du système de virtualisation KVM (Kernel based Virtual Machine) intégré au système GNU/Linux. 2 ) Eco-système de l'environnement KVM Kernel based Virtual Machine (KVM) est un environnement de virtualisation initialement développé par la société Qumranet. Il est nativement intégré au noyau GNU/Linux depuis la version 2.6.20. L'éditeur Red Hat, qui a racheté Qumranet en 2008, l'a adopté comme principal mécanisme de virtualisation afin de se positionner sur le marché concurrentiel de la virtualisatiion face aux solutions d'autres éditeurs tels VmWare (VmWare ESX), Microsoft(Hyper-V) et Citrix (XEN), Oracle (OracleVM et Virtualbox)... pour ne citer que les plus médiatiquement connus. KVM est un système de virtualisation complète (full virtualization) s'appuyant sur les mécanismes de virtualisation matérielle (HVM Hardware Virtual Machine) intégrés aux dernières générations de processeurs. HVM se traduit par l'extension du jeu d'instructions des processeurs fournissant une assistance matérielle à la virtualisation. Extensions nommées VMX (Virtual Machine extensions) chez Intel, SVM (Secure Virtual Machine) chez AMD. Bien qu'elles soient spécifiques à chaque constructeur, KVM en présente une interface unifiée au niveau du noyau du système de la machine hôte (la machine physique). Concrètement KVM se présente sous la forme de deux modules du noyau GNU-Linux que l'on charge lors du démarrage de la machine hôte. Un simple test du jeu d'instructions du processeur de la machine hôte permet de choisir le module kvm-intel ou kvm-amd à charger. En l'absence du module, soit parce que le processeur de l'hôte est ancien et ne dispose pas des extensions de virtualisation, soit celles ci sont présentes dans le processeur mais inactives, car verrouillées par le BIOS de la machine, la virtualisation KVM fonctionnera avec des performances moindres. Sur des machines anciennes cette baisse de performances, étant trop importante, peut entrainer des dysfonctionnements des machines virtuelles. Ouvrez un terminal de commandes, en enchainant les menus «K Applications System Terminal (Konsole)» ou en cliquant sur l'icone d'un terminal dans le coin inférieur droit du bureau Viminal. Testez la présence des extensions du jeu d'instruction en affichant les caractéristiques du processeur de la machine hôte à l'aide de la commande «cat /proc/cpuinfo». TELECOM Lille 1 J. Landru 9 / 39 V1.1-20120221

viminal@livecd~$ cat /proc/cpuinfo Note : Pour les processeurs multi-coeurs, les informations sont affichées pour chacun des coeurs. Si l'attribut «flags» contient la sous chaine «vmx», vous êtes en présence d'un processeur Intel disposant des extensions HVM, si l'attribut «flags» contient la sous chaine «svm» vous êtes en présence d'un processeur AMD disposant des extensions HVM, sinon la machine hôte ne dispose pas de l'assistance matérielle à la virtualisation, les performances des machines virtuelles seront alors faibles. Afin de faciliter la détection vous pouvez filtrer l'affichage de la commande en la redirigeant vers la commande «grep» à l'aide du «pipe unix» (caractère ) Dans le cas d'un processeur Intel viminal@livecd~$ cat /proc/cpuinfo grep vmx Dans le cas d'un processeur AMD : viminal@livecd~$ cat /proc/cpuinfo grep svm Si les extensions HVM sont présentes sur l'hôte, nous allons charger le module noyau d'accélération matérielle. Sur une machine Intel, tapez la commande suivante : viminal@livecd~$ sudo modprobe kvm-intel Sur une machine AMD, tapez la commande suivante : viminal@livecd~$ sudo modprobe kvm-amd L'absence de message d'erreur confirme le bon déroulement de l'opération que l'on peut facilement vérifier en listant les modules du noyau au moyen de la commande lsmod. viminal@livecd~$ lsmod grep kvm L'échec du chargement du module, malgré le présence des extensions HVM au niveau du processeur, indique que celles ci ont été invalidées au niveau du BIOS de la machine hôte, si vous ne pouvez les activer, les performances des machines virtuelles seront faibles. L'outil de base pour le contrôle de machines virtuelles KVM est une version adaptée du célèbre émulateur de matériel QEMU développé par Fabrice Bellard. Nota : QEMU permet d'émuler plusieurs types d'architecture matérielle sur différents systèmes hôtes. Un émulateur de matériel permet de faire tourner des systèmes (OS) ou des applicatifs destinés à d'autres architectures matérielles (processeurs, bus, entrées/sorties, bios) sur votre TELECOM Lille 1 J. Landru 10 / 39 V1.1-20120221

poste bâti sur un matériel différent. Il est ainsi possible de faire tourner un Linux pour processeur embarqué de type ARM sur votre machine Intel X86. Cette souplesse a toutefois un coût important en terme de performances. La version modifiée, dénommée qemu-kvm permet, en s'appuyant sur le module que l'on vient de charger, de tirer profit des extensions HVM et d'atteindre des performances de machine virtuelle proches des performances natives de la machine hôte. Affichez les paramètres de la commande kvm en la sollicitant avec l'option «--help». viminal@livecd~$ kvm --help Affichez le détails des options à l'aide de la commande «man qemu» viminal@livecd~$ man qemu 2.1 ) Votre première machine virtuelle avec KVM Pour cette première machine virtuelle KVM, nous allons utiliser une distribution GNU/Linux dite «livecd». Nota : Ce type de distribution permet de lancer un environnement GNU/Linux complet depuis un CD ou un DVD sans l'installer sur sa machine. Très utile pour tester ou découvrir GNU/Linux sans altérer le système pré-existant sur la machine d'accueil (en général un système MS- Windows), le livecd ou livedvd est également très courant pour les procédures d'installation de la plupart des distributions GNU/LInux. Les livecd découvrent automatiquement les composants matériels de la machine d'accueil avant de lancer un bureau graphique qui donnera accès à tout un ensemble de commodités. Nous allons utiliser la distribution «live» dénommée Slitaz. Il s'agit d'une distribution livecd dont l'objectif est de conserver un fichier iso de taille très réduite de quelques dizaines de Méga-octets. Elle peut de cette manière être gravée sur des supports de type CD format carte de crédit ou tout autre support iso de taille réduite telles que le clés USB. Nous allons démarrer la machine virtuelle pourvue de 256 Mo de mémoire et d'un lecteur CDrom qui pointera sur le fichier iso du livecd. Le fichier iso du livecd Slitaz est localisé dans le répertoire /usr/local/share/viminal/filesystems. La commande suivante «kvm -cdrom /usr/local/share/viminal/filesystems/slitaz- 2.0.iso -m 256 -vga std -boot d» démarre une machine virtuelle de 256 Mo de ram (paramètre -m) muni d'un écran vga standard (-vga std) d'un lecteur de CDrom contenant le CD Slitaz-2.0 (option -cdrom). Le démarrage (boot) de la machine se fera sur le lecteur de CD (option -boot d). viminal@livecd~$ kvm -cdrom /usr/local/share/viminal/filesystems/slitaz-2.0.iso -m 256 -vga std -boot d Nota : Si vous ne disposez pas des extensions HVM et que vous avez la patience d'attendre le démarrage complet de la machine virtuelle, vous devez ajouter l'option -no-kvm à vos commandes kvm, pour que la machine virtuelle Slitaz puisse démarrer avec succès. TELECOM Lille 1 J. Landru 11 / 39 V1.1-20120221

Nota : Le démarrage de la distribution Slitaz vous permet de sélectionner la résolution de l'écran de votre machine virtuelle. Veillez à sélectionner une résolution inférieure à celle de votre machine hôte. En sélectionnant une résolution de 800x600 vous garderez un contrôle plus aisé de votre machine virtuelle. Nota : Lorsque vous cliquez dans l'écran de la machine virtuelle vos périphériques d'entrée «clavier / souris» sont captés et restent confinés à l'écran de la machine virtuelle. L'appui simultané sur les touches «Ctrl» et «Alt», vous permettra de les libérer pour reprendre le contrôle du bureau de votre machine hôte (machine réelle). Affichez maintenant les caractéristiques de la machine virtuelle. Option «Menu system Tools System Information» (ou cliquez sur l'icone d'un écran barré d'un point d'exclamation en bas à droite du bureau Slitaz). Observez les caractéristiques CPU, mémoire, Cdrom, Réseau de votre machine virtuelle. Stoppez maintenant cette première machine virtuelle (Option «Menu Shutdown computer»). Logout 2.2 ) Installation d'un système dans la machine virtuelle. Nous allons maintenant procéder à l'installation du système sur une machine virtuelle. Comme une machine réelle, la VM a besoin d'un espace de stockage de type disque virtuel qui sera associé à la machine virtuelle. Ce disque peut : résider localement sur la machine hôte, soit sous la forme d'un disque réel (/dev/hdax ou /dev/sdx), soit sous la forme d'un volume logique type LVM (Logical Volume Manager), soit encore sous la forme d'un simple fichier brut (fichier «raw»), être déporté sur un réseau sous forme de volume logique ou d'un fichier «raw,» résidant sur un NAS (Network Attached Storage) ou sur un réseau de stockage hautes performances dédié de type SAN (Storage Area Network) ISCSI ou FC (Fiber chanel). Dans le cadre de ce TP, nous allons créer un disque virtuel local sous la forme d'un fichier brut (raw) que nous allons associer à la machine virtuelle. Nous créons tout d'abord un répertoire dénommé rootfs-store, localisé sur /tmp. Ce répertoire nous servira de dépôt pour les disques virtuels de nos VM. viminal@livecd~$ mkdir /tmp/rootfs-store Nous allons créer un disque virtuel de 300 Méga-octets en nous allouant un fichier nommé vm-disk.img de la taille correspondante à l'aide de la commande «dd if=/dev/zero of=/tmp/rootfs-store/vm-disk.img seek=300 count=1 bs=1m» Le paramètre «if» indique que l'on crée un fichier rempli de zéro binaire, le paramètre «of» indique le nom du fichier à créer. Les paramètres suivants «seek=300 count=1 bs=1m» indiquent la taille du fichier à créer. viminal@livecd~$ dd if=/dev/zero of=/tmp/rootfs-store/vm-disk.img TELECOM Lille 1 J. Landru 12 / 39 V1.1-20120221

seek=300 count=1 bs=1m Vérifiez le résultat de la création, en affichant le contenu du répertoire /tmp/rootfsstore. viminal@livecd~$ ls -al /tmp/rootfs-store Procédez à l'installation de la distribution Slitaz sur ce disque. Pour cela redémarrez la machine virtuelle en «bootant sur le CDrom» et en lui associant comme disque «hda» (le premier disque de l'interface IDE de la machine virtuelle) le fichier que l'on vient de créer. L'option supplémentaire «-daemonize» permet de lancer le processus KVM en arrière plan (en mode «daemon»), ce qui permet de récupérer le «prompt» de commande du terminal. viminal@livecd~$ kvm -cdrom /usr/local/share/viminal/filesystems/slitaz-2.0.iso -m 256 -vga std -boot d -hda /tmp/rootfs-store/vm-disk.img -daemonize Nota : Si vous ne disposez pas des extensions HVM et que vous avez la patience d'attendre le démarrage complet de la machine virtuelle, vous devez ajouter l'option -no-kvm à vos commandes kvm, pour que la machine virtuelle Slitaz puisse démarrer avec succès. Nota : Le démarrage de la distribution Slitaz vous permet de sélectionner la résolution de l'écran de votre machine virtuelle. Veillez à sélectionner une résolution inférieure à celle de votre machine hôte. En sélectionnant une résolution de 800x600 vous garderez un contrôle plus aisée de votre machine virtuelle. Nota : Lorsque vous cliquez dans l'écran de la machine virtuelle vos périphériques d'entrée «clavier / souris» sont captés et restent confinés à l'écran de la machine virtuelle. L'appui simultané sur les touches «Ctrl» et «Alt», vous permettra de les libérer pour reprendre le contrôle du bureau de votre machine hôte (machine réelle). Dès que la machine est complètement démarrée, affichez les caractéristiques de la machine virtuelle. Option «Menu system Tools System Information» (ou cliquez sur l'icone d'un écran barré d'un point d'exclamation en bas à droite du bureau Slitaz) et constatez la présence du disque (Devices Storage IDE disks QEMU Harddisk). Dans la machine virtuelle, ouvrez un terminal de commande en mode super utilisateur («root»). Enchainez les menus «menu utilities Xterm Terminal», ou cliquez sur l'icone symbolisant un terminal en bas à gauche du bureau Slitaz. Passez en privilège super utilisateur à l'aide de la commande «su -». A la demande de mot de passe tapez «root». Le prompt de commande devient «#» ce qui indique que vous avez maintenant les privilèges du super utilisateur au sein de la machine virtuelle. Comme pour toute installation de distribution GNU/Linux sur un support disque, il nous faut préparer le disque en le partitionnant. Le disque hda que nous avons associé à la machine virtuelle est pour le moment un disque brut. La commande «fdisk -l /dev/hda» qui tente de nous afficher le partitionnement du disque, nous indique que le disque hda ne contient pas de table des partition. TELECOM Lille 1 J. Landru 13 / 39 V1.1-20120221

tux@slitaz:~$ su - password : root@slitaz~# fdisk -l /dev/hda... Disk /dev/hda doesn't contain a valid partition table Nous allons donc partitionner le disque pour qu'il puisse accueillir l'installation de la distribution. Par simplicité et facilité, dans le cadre de ce TP, nous ne créerons qu'une seule partition(pas de partition de swap, pas de partition /boot, /home, /tmp, /var, ). A l'aide de la commande fdisk, créez une partition primaire qui occupe la totalité du disque avec l'attribut «bootable». root@slitaz~# fdisk /dev/hda Appuyez sur la touche «m» pour avoir de l'aide. Enchainez les commandes suivantes La touche «n», (new) permet la création d'une nouvelle partition. Sélectionnez «p» (primaire : primary partition), puis sélectionnez «1» pour le numéro de partition (partition number (1-4)), enfin valider les choix par défaut (début : First Cylinder et fin : Last cylinder) pour que votre partition occupe la totalité du disque. Positionnez l'attribut «partition de démarrage» (toggle a bootable flag) sur la partition 1 que vous venez de créer par l'appui sur la touche «a» puis en choisissant la 1ere partition (Partition number (1-4)). Quittez en écrivant la table des partitions par l'appui sur la touche «w» Remarque : si vous faites une fausse manipulation durant l utilisation de fdisk, quittez l application sans enregistrer les modifications (touche «q») et recommencez. Vérifiez votre table des partitions en l'affichant à l'aide de la commande «fdisk -l» root@slitaz~# fdisk -l /dev/hda Si l'affichage ne correspond pas strictement à celui ci dessous, recommencez l'opération. root@slitaz~# fdisk -l /dev/hda Disk /dev/hda: 315 MB, 315621376 bytes 255 heads, 63 sectors/track, 38 cylinders Inits = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 38 305203+ 83 Linux Nous pouvons maintenant procéder à l'intallation de la distribution Slitaz sur le disque de la machine virtuelle, à l'aide de la commande «slitaz-installer». TELECOM Lille 1 J. Landru 14 / 39 V1.1-20120221

root@slitaz~# slitaz-installer A la question «Partition to use:» saisissez /dev/hda1. Puis acceptez le formatage au format ext3. Pour les choix suivants acceptez les choix par défaut. A l'issue de l'installation, stoppez la machine virtuelle (Option «Menu Shutdown computer») Logout Nota : A l'issue de l'installation, le système slitaz installé dispose de deux comptes utilisateur, un utilisateur sans privilège particulier (login : «tux», mot de passe «tux», et un «superutilisateur» disposant de tous les privilèges administratifs (login «root» et mot de passe «root»). Nous disposons maintenant d'une machine virtuelle autonome qui ne dépend plus de son CD. Nous pouvons la lancer comme n'importe quel ordinateur en la démarrant depuis son disque. Testez votre machine virtuelle. On modifie l'option «-boot» en la positionnant à la valeur «c» pour indiquer de démarrer sur le disque. On ajoute l'option «-name» afin de nommer l'instance de la machine virtuelle. Ce nom apparaitra notamment sur le titre de la fenêtre correspondant à l'écran de la machine, ce qui permettra de la distinguer lorsque nous lancerons simultanément plusieurs machines. viminal@livecd~$ kvm -m 256 -vga std -hda /tmp/rootfs-store/vmdisk.img -boot c -name slitaz -daemonize Logger vous sous l'utilisateur «tux» (mot de passe «tux»), observez les caractéristiques CPU, mémoire, Cdrom, réseau de votre machine virtuelle. Stoppez maintenant cette première machine virtuelle (Option «Menu Shutdown computer»). Logout Le fichier vm-disk.img contient un système de fichiers complet. Dans les environnements de type Unix, il est couramment appelé système de fichiers racine ou «rootfs». C'est ce terme que nous utiliserons dans la suite de ce TP. 2.3 ) «Faisons les clones» Nous allons maintenant, sur la base de cette première machine virtuelle, créer de nouvelles machines identiques. En un mot nous allons cloner les machines virtuelles. Deux approches peuvent être utilisées : Réplication : Il s'agit tout simplement de dupliquer le fichier disque virtuel (rootfs) que nous avons créé dans l'étape précédente. La création d'une nouvelle machine identique à la première se résume à. la commande «cp /tmp/rootfsstore/vm-disk.img /tmp/rootfs-store/vm02-disk.img». Ces machines virtuelles jumelles disposent ainsi chacune de leur disque (rootfs) sur lequel des applications ou des configurations différentes pourront être installées. Cette approche simple, est cependant gourmande en espace disque, car le patrimoine génétique (système de base, noyau linux,...) commun aux systèmes clonés est répliqué autant de fois qu'il y a de clones. Ainsi si nous voulions créer 5 clones, il nous faudrait disposer de 5 fois l'espace disque de la machine initiale (soit dans TELECOM Lille 1 J. Landru 15 / 39 V1.1-20120221

notre cas 1,5 Go (5 x 300 Mo)). Fichier de débordement (Copy On Write) : Comme il contient un système de fichiers complet, la taille d'un fichier rootfs d'une machine virtuelle peut être importante. Le système de virtualisation User-Mode Linux a introduit la possibilité à plusieurs machines virtuelles de se partager un rootfs commun en lecture seule. Les opérations d'écriture de chacune des machines virtuelles sont déportées dans des fichiers séparés propres à chaque machine virtuelle. Figure 1 - Partage d'un système de fichiers commun Les machines virtuelles disposent donc d'un espace de débordement (overlay) dans lequel sont stockées les surcharges apportées au système de fichiers de référence. Ces fichiers de débordement ne contenant que les différences avec le rootfs, sont dénommés fichiers COW (abréviation de Copy On Write). Ils sont liés au fichier rootfs commun et sont de taille modeste. L'utilisation des fichiers COW permet donc de personnaliser un ensemble de machines virtuelles, partageant par ailleurs une base système commune. Le clonage d'un système de base de référence devient une opération très facile. Les machines virtuelles VM1 et VM2 de la Figure 1 disposent ainsi de leur propre système de fichiers ne contenant que les différences avec le système de fichiers de référence qu'est le rootfs. «Vachement bien» les fichiers COW : Ce système COW introduit une certaine souplesse de gestion. Le premier avantage de ce système COW est l'optimisation de taille. L'unique et volumineux rootfs est partagé pour un ensemble de machines virtuelles clonées. La différentiation de ces VM est déportée dans de petits fichiers. Les environnements de virtualisation libres XEN et KVM/QEMU peuvent exploiter les fichiers COW. QEMU a même amélioré le format en créant les formats QCOW et QCOW2 qui peuvent être chiffrés et compressés. Toutefois, il convient de noter que les fichiers COW sont liés au fichier de référence par un ensemble de pointeurs internes. Ceux ci référencent les blocs de données modifiés par rapport au rootfs de référence. Ce lien fort entre le fichier COW et le rootfs de référence interdit toute modification de ce dernier. En effet en cas d'altération du système de fichiers de référence, l'ensemble des fichiers COW qui lui sont liés deviennent incohérents et inutilisables. La mise à jour du kernel ou de la distribution, l'application de patches de sécurité, doit alors être effectuée sur chacun des clones. A partir de ce moment la lignée de clones va commencer à diverger. (Des techniques d'unification permettent de s'affranchir de ce lien fort de dépendance. Leur mise en oeuvre dépasse le cadre de ce TP. L'une d'elle, dénommée GUSTAV, publiée aux congrès TELECOM Lille 1 J. Landru 16 / 39 V1.1-20120221

JRES2009 est accessible à l'url suivante https://2009.jres.org/planning, une copie de l'article est également disponible sur ce livecd /usr/local/share/viminal/vodka/instructionsheets/docs/jres2009-article-14.pdf). Nous allons maintenant cloner notre machine virtuelle à l'aide de la technique COW (Copy On Write). La commande «qemu-img» permet de créer et manipuler les fichiers image (rootfs) des machines virtuelles. Tapez la commande sans paramètre pour en afficher la syntaxe. Consulter également les pages manuel de cette commande. viminal@livecd~$ qemu-img viminal@livecd~$ man qemu-img Nous allons créer deux clones ayant comme rootfs de référence le fichier vm-disk.img créé à l'étape précédente. La commande «qemu-img create -f qcow2 -o backing_file=/tmp/rootfs-store/vm-disk.img /tmp/rootfs-store/vm01- disk.qcow2» crée un premier rootfs cloné. L'option «-f» permet de spécifier le format du fichier, qcow2 dans notre cas. L'option «-o backing_file=/tmp/rootfsstore/vm-disk.img» indique que le fichier créé est un fichier de débordement (Copy On Write) pointant sur le fichier de référence indiqué par le paramètre backing_file. viminal@livecd~$ qemu-img create -f qcow2 -o backing_file=/tmp/rootfs-store/vm-disk.img /tmp/rootfs-store/vm01- disk.qcow2 Observer le résultat en listant le contenu du répertoire /tmp/rootfs-store. viminal@livecd~$ ls -al /tmp/rootfs-store Quelle est la taille du fichier vm01-disk.qcow2 comparativement au fichier de référence? Créer le second fichier cloné. viminal@livecd~$ qemu-img create -f qcow2 -o backing_file=/tmp/rootfs-store/vm-disk.img /tmp/rootfs-store/vm02- disk.qcow2 Nous pouvons maintenant démarrer les deux clones pointant sur le même fichier de référence. Celui ci est accédé en lecture seule par les deux clones. Toutes les opérations d'écriture sont déportées dans les fichiers de débordement (Copy On Write). Démarrage du premier clone : TELECOM Lille 1 J. Landru 17 / 39 V1.1-20120221

viminal@livecd~$ kvm -m 256 -vga std -hda /tmp/rootfs-store/vm01- disk.qcow2 -boot c -name slitaz-vm01 -daemonize Démarrage du second clone : viminal@livecd~$ kvm -m 256 -vga std -hda /tmp/rootfs-store/vm02- disk.qcow2 -boot c -name slitaz-vm02 -daemonize Chaque clone à maintenant sa propre vision du rootfs de référence. Sur la machine slitazvm01 créer un fichier de 10 Mo sur le répértoire /tmp. Ouvrez un terminal de commande et lancez la commande suivante «dd if=/dev/null of=/tmp/my-10mo-file seek=10 count=1 bs=1m». tux@slitaz-vm01:~$ dd if=/dev/null of=/tmp/my-10mo-file seek=10 count=1 bs=1m 0+0 records in 0+0 records out tux@slitaz-vm01:~$ ls -al /tmp Sur la machine hôte, observez maintenant la taille des fichiers qcow2 correspondant au deux machines virtuelles. Nota : Les mécanismes de cache en écriture de la machine hôte peuvent différer la mise à jour du fichier qcow2. viminal@livecd:~$ ls -als /tmp/rootfs-store Le rootfs de référence n'a subi aucune modification, alors que les deux fichiers qcow2 évoluent en fonction des changements d'état des clones. La commande «qemu-img info» permet d'avoir le détails de la configuration d'un rootfs. Lancez les commandes suivantes et observez les caractéristiques des différents rootfs. viminal@livecd:~$ qemu-img info /tmp/rootfs-store/vm-disk.img viminal@livecd:~$ qemu-img info /tmp/rootfs-store/vm01-disk.qcow2 viminal@livecd:~$ qemu-img info /tmp/rootfs-store/vm02-disk.qcow2 TELECOM Lille 1 J. Landru 18 / 39 V1.1-20120221

2.4 ) Connexion au réseau. 2.4.a ) Connectivité des VM Il existe deux modes de connexion des VM au réseau. Ils sont utilisés, à quelques variantes près, par la plupart des systèmes de virtualisation. Le mode translaté (NAT) : Dans ce mode (mode par défaut, dit «user», dans l'environnement QEMU-KVM,) la machine virtuelle est prise en charge par l'environnement de virtualisation qui se présente comme un firewall dédié qui contrôle l'ensemble du trafic de la VM. Ce firewall fournit les fonctions de server DHCP, de relai DNS et de routeur intégrant la translation NAT/PAT avec la connexion de la machine hôte. La machine virtuelle est confinée dans l'espace de contrôle du processus de virtualisation. Ce confinement est tel, que plusieurs clones peuvent avoir les mêmes adresses MAC et IP sans que cela ne crée de perturbation. Dans le cas de QEMU, l'adresse MAC par défaut à la valeur 52:54:00:12:34:56, le Firewall du processus QEMU adresse les machines virtuelles sur le réseau privé (RFC1918) 10.0.2.0/24. Les communications des machines virtuelles sont translatées sur l'adresse de l'hôte. Observez les configurations réseau de chacun des clones à l'aide de la commande «ifconfig» tux@slitaz-vm01:~$ ifconfig tux@slitaz-vm02:~$ ifconfig Constatez que les configurations sont bien identiques. Ce mode translaté (NAT) est facile à mettre en oeuvre, car il est nativement intégré au processus de virtualisation. Il permet aux machines virtuelles d'accéder au réseau en utilisant les mêmes autorisations/restrictions que l'hôte. Il offre l'avantage d'isoler strictement dans un bac à sable chaque machine virtuelle. Par contre les machines virtuelles ne sont pas accessibles depuis l'extérieur du bac à sable. Seuls les flux sortants sont possibles. Les VM ne sont pas visibles des autres machines du réseau physique. Elles ne sont pas intégrées au réseau de l'entreprise sur lequel est connectée la machine qui les héberge (l'hôte). Dans le cas de notre TP, les deux clones slitaz-vm01 et slitazvm02 ne peuvent pas se «pinguer» mutuellement. Le mode «ponté» (Bridged) : Dans ce mode, et ses variantes, les machines virtuelles vont être intégrées au réseau de l'entreprise au même titre que l'hôte lui même. Vu du réseau, rien ne permettra de distinguer une machine physique, d'une machine virtuelle. Un commutateur ethernet virtuel,sous forme logiciel, est mis en oeuvre sur la machine hôte. Il s'agit d'un processus de l'hôte qui va simuler le comportement d'un commutateur, sur lequel viendront se connecter les interfaces virtuelles des VM, ainsi qu'éventuellement la ou les interfaces physique (carte TELECOM Lille 1 J. Landru 19 / 39 V1.1-20120221

ethernet) de l'hôte pour l'accès au réseau physique. Pour que cela fonctionne, il faut que l'interface virtuelle réseau de chaque machine virtuelle dispose d'une adresse MAC unique. Il existe différents commutateurs logiciels qui peuvent être utilisés. Ils se distinguent par leur performances et leur capacité de contrôle. Dans le cadre de ce TP nous utiliserons le commutateur virtuel nativement intégré au noyau GNU/Linux de la machine hôte. Il est contrôlé par la commande «brctl». Mise en oeuvre du mode «ponté» Stoppez les deux machines virtuelles slitaz-vm01 et slitaz-vm02, (Option «Menu Logout Shutdown computer»). Création d'un commutateur virtuel sur la machine hôte : La commande «brctl» est réservée à l'usage du super utilisateur (root). Nous ferons appel à la commande «sudo» afin de bénéficier provisoirement des privilèges du super utilisateur. Créez un commutateur (bridge) nommé br0 sur la machine hôte. Configurez son adresse IP sur le réseau 192.168.1.0/24 (*) et activez le. (*) Si une des interfaces (eth0, eth1,...) de votre machine hôte dispose déjà d'une adresse sur ce réseau IP, choisissez un autre réseau du plan d'adressage de la RFC1918. viminal@livecd:~$ sudo brctl addbr br0 viminal@livecd:~$ sudo ifconfig br0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up Nota : L'intégration de la mise en oeuvre automatique du commutateur lors de la séquence de démarrage (boot) de la machine hôte est dépendant de la distribution GNU/Linux de l'hôte (Debian, RedHat, Gentoo, Suse, Slackware,...) et dépasse le cadre de ce TP. Nota : La mise en oeuvre et la gestion de domaines de diffusion distincts (VLAN) dépassent le cadre de ce TP. Nota : Dans le cadre de ce TP, la carte ethernet (eth0) de la machine hôte, n'est pas connectée au commutateur virtuel br0, afin de ne pas perturber le réseau du laboratoire. Vos machines virtuelles ne sont donc pas connectées au réseau du laboratoire. Comme les machines virtuelles de chacune des positions de travail ont toutes les mêmes adresses MAC, elles ne peuvent (doivent) pas résider sur le même domaine de diffusion (VLAN du laboratoire). Nous devons également créer une interface Ethernet virtuelle (tun/tap) pour chacune des machines virtuelles. Ces interfaces seront associées aux machines virtuelles lors du démarrage des VM. viminal@livecd:~$ sudo tunctl -u viminal -t tap1 viminal@livecd:~$ sudo tunctl -u viminal -t tap2 Connectez ces interfaces virtuelles au commutateur virtuel br0 à l'aide de la commande «brctl». TELECOM Lille 1 J. Landru 20 / 39 V1.1-20120221

viminal@livecd:~$ sudo ifconfig tap1 0.0.0.0 up viminal@livecd:~$ sudo brctl addif br0 tap1 viminal@livecd:~$ sudo ifconfig tap2 0.0.0.0 up viminal@livecd:~$ sudo brctl addif br0 tap2 Vérifiez les interfaces raccordées au «bridge» br0. viminal@livecd:~$ sudo brctl show Nous pouvons maintenant démarrer les machines virtuelles en leur associant une carte ethernet (paramètre «-net nic») associée à son interface tap respective (paramètre «-net tap». Nota : Attention à bien fournir une adresse MAC unique à chaque carte ethernet. viminal@livecd~$ kvm -m 256 -vga std -hda /tmp/rootfs-store/vm01- disk.qcow2 -boot c -name slitaz-vm01 -daemonize -net nic,macaddr=52:54:00:f1:f1:f1 -net tap,vlan=0,ifname=tap1,script=no viminal@livecd~$ kvm -m 256 -vga std -hda /tmp/rootfs-store/vm02- disk.qcow2 -boot c -name slitaz-vm02 -daemonize -net nic,macaddr=52:54:00:f2:f2:f2 -net tap,vlan=0,ifname=tap2,script=no Une fois que les machines ont démarré, pour chacune d'elle configurez les paramètres réseau : Ouvrez un terminal de commande, passez en mode super-utilisateur (root) au moyen de la commande «su -». Sauvegardez le fichier de configuration réseau d'origine en le renommant avec l'extension «.orig». Puis à l'aide de l'éditeur «leafpad» créez le nouveau fichier de configuration réseau en respectant strictement la syntaxe indiquée ci dessous. Sur slitaz-vm01 configurez l'interface eth0 avec l'adresse 192.168.1.101 : tux@slitaz:~$ su - password : root@slitaz~# mv /etc/network.conf /etc/network.conf.orig root@slitaz~# leafpad /etc/network.conf... TELECOM Lille 1 J. Landru 21 / 39 V1.1-20120221

Saisissez les lignes suivantes en respectant strictement la casse (minuscules/majuscules) et les guillemets et sauvegardez le fichier. INTERFACE="eth0" STATIC="yes" IP="192.168.1.101" NETMASK="255.255.255.0" GATEWAY="" Configurez l'interface eth0 root@slitaz~# /etc/init.d/network.sh start /etc/network.conf Ne tenez pas compte du message d'avertissement relatif à la commande route, car nous n'avons pas de passerelle par défaut dans le cadre de ce TP. Vérifiez la configuration en affichant l'adresse de l'interface eth0 root@slitaz~# ifconfig -a Sur slitaz-vm02 configurez l'interface eth0 avec l'adresse 192.168.1.102 : tux@slitaz:~$ su - password : root@slitaz~# mv /etc/network.conf /etc/network.conf.orig root@slitaz~# leafpad /etc/network.conf... Saisissez les lignes suivantes en respectant strictement la casse (minuscules/majuscules) et les guillemets et sauvegardez le fichier. INTERFACE="eth0" STATIC="yes" IP="192.168.1.102" NETMASK="255.255.255.0" GATEWAY="" Configurez l'interface eth0 root@slitaz~# /etc/init.d/network.sh start /etc/network.conf Ne tenez pas compte du message d'avertissement relatif à la commande route, car nous n'avons pas de passerelle par défaut dans le cadre de ce TP. Vérifiez la configuration en affichant l'adresse de l'interface eth0 TELECOM Lille 1 J. Landru 22 / 39 V1.1-20120221

root@slitaz~# ifconfig -a Puis «pinguez» slitaz-vm02 à partir de slitaz-vm01. Sur slitaz-vm01 : root@slitaz~# ping -c 5 192.168.1.102 Le succès du ce ping confirme que vos deux machines virtuelles sont bien connectées sur le même réseau au travers du bridge «br0». Pinguez slitaz-vm01 depuis le host viminal sur l'hôte viminal : viminal@livecd:~$ ping -c 5 192.168.1.101 Pinguez l'hôte viminal depuis la machine virtuelle slitaz-vm01. Sur slitaz-vm01 : root@slitaz~# ping -c 5 192.168.1.1 Le succès de ces deux derniers ping confirme la connectivité entre votre machine hôte (viminal) et les deux machines virtuelles au travers du bridge «br0». Stoppez les clones avant de passer à la suite. 2.5 ) La boite à outils libvirt Libvirt est une boite à outils pour la virtualisation. Soutenue et développée à l'initiative de RedHat (http://libvirt.org), ce projet libre vise à offrir une couche d'abstraction commune à plusieurs environnements de virtualisation (au moment de la rédaction de ce TP, libvirt supporte les environnements de virtualisation suivants : KVM, QEMU, XEN, LXC, OpenVZ, User Mode Linux, VirtualBox, VMWare ESX et GSX). Libvirt comporte : une libraire fournissant les appels système de communication et de contrôle du système de virtualisation (hyperviseur), un daemon dénommé libvirtd, un format de description des VM au format XML, un ensemble d'api de liaison pour l'intégration dans différents langages de haut niveau (Python, Perl, Ocaml, Ruby, Java, c#), virsh (Virtualization Shell), un ensemble de commande interactive, pour le contrôle des VM directement depuis le shell de commande ou pour l'intégration dans des scripts systèmes, TELECOM Lille 1 J. Landru 23 / 39 V1.1-20120221

un ensemble d'outils de gestion de VM tels que virt-install, virt-clone, virt-image, virt-df, virt-top, libvirt est également le socle de base pour les applications de gestion d'un parc de machines virtuelles telles virt-manager (que nous découvrirons à la fin de ce TP), mais aussi ovirt, AbiCloud,...). Lancer le daemon «libvirtd» à l'aide de la commande «sudo /etc/init.d/libvirtd start». L'usage de sudo est nécessaire car le daemon nécessite les droits du super utilisateur. viminal@livecd:~$ sudo /etc/init.d/libvirtd start 2.5.a ) Création d'une machine virtuelle avec libvirt Dans l'environnement libvirt, chaque machine virtuelle est décrite dans un fichier xml généré lors de la création/installation de la VM. L'outil virt-install est chargé de cette opération. Il comprend de nombreux paramètres, qui sont décrit dans la page manuel («man virt-install»). Nous allons créer une instance de VM correspondant au clone slitaz-vm01 de l'étape précédente à l'aide de la commande «sudo virt-install - name=slitaz-vm01 - ram=256 - disk=/tmp/rootfs-store/vm01-disk.qcow2,device=disk,format=qcow2 - vnc keymap=fr -video=vga - network=bridge=br0 - accelerate --import». Cette commande va créer le fichier de description xml, puis lancer la machine pour procéder à l'installation du système. Comme nous avons déjà installé l'os nous spécifions l'option import, qui démarrera directement la machine sur son disque. Nota : «virt-install» nécessite les privilèges du super-utilisateur pour créer dynamiquement l'interface «tap» pour la machine virtuelle. Aussi nous le lançons avec la command «sudo». viminal@livecd:~$ sudo virt-install - name=slitaz-vm01 - ram=256 -disk=/tmp/rootfs-store/vm01-disk.qcow2,device=disk,format=qcow2 -vnc -keymap=fr -video=vga -network=bridge=br0 - accelerate --import La description de la machine virtuelle sous forme de fichier xml est créée (fichier /home/viminal/.libvirt/qemu/slitaz-vm01.xml) et la machine est démarrée. Connectez vous à cette machine à l'aide de l'outil virt-viewer. Ouvrez un nouveau shell (konsole sous KDE) et lancez la commande suivante pour afficher l'écran de votre machine virtuelle «virt-viewer -c qemu:///system slitaz-vm01». viminal@livecd:~$ virt-viewer -c qemu:///system slitaz-vm01 & TELECOM Lille 1 J. Landru 24 / 39 V1.1-20120221

Nota : Lancez la commande en arrière plan en suffixant la commande par un «&», afin de récupérer le prompt de commande de votre shell. L'écran de la machine s'affiche et vous pouvez interagir directement dessus. (l'appui simultané sur les touches «ctrl-alt» vous permet de libérer les périphériques d'entrée (clavier / souris). Un fois la machine complètement démarrée, stoppez là (Option «Menu Shutdown computer») avant de passer à la suite. Logout Affichez le contenu du fichier /home/viminal/.libvirt/qemu/slitaz-vm01.xml à l'aide de la commande «sudo less». *le fichier, ayant été créé avec les droits superutilisateur, n'est lisible que par ce dernier. viminal@livecd:~$ sudo less /home/viminal/.libvirt/qemu/slitazvm01.xml Observez comment le différentes caractéristiques de la machine, que vous avez spécifiées dans la commande «virt-install», ont été transposées dans le format xml. Notez également que virt-install génère, pour chaque machine créée, une adresse MAC ethernet aléatoire afin de minimiser les risques de collision d'adresse MAC. 2.5.b ) Contrôle de la machine virtuelle avec virsh Virsh peut s'utiliser selon deux modes. Le mode interactif : Un nouveau prompt de commande, donne accès à tout un ensemble de commandes qui agiront sur les machines (appelées «domaine»), la commande help vous indiquera l'ensemble des commandes. Le mode direct : en spécifiant, lors de l'appel à virsh, quelle opération effectuer sur l'une des machines virtuelles (domaines). Dans ce mode l'appel à virsh peut être fait depuis un script. Démarrez virsh en mode interactif sur l'instance locale de qemu, en tapant la commande «sudo virsh» sans paramètre. viminal@livecd:~$ sudo virsh Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # Notez que le prompt de commande a changé. Tapez «help» pour avoir un aperçu des commandes disponibles. virsh # help TELECOM Lille 1 J. Landru 25 / 39 V1.1-20120221

Pour libvirt chaque machine virtuelle est un domaine, dont les caractéristiques sont stockées dans les fichiers xml de description. Pour activer une machine virtuelle lancer la commande «create <nom-du-fichier.xml>» virsh # create /home/viminal/.libvirt/qemu/slitaz-vm01.xml Domain slitaz-vm01 created from /home/viminal/.libvirt/qemu/slitaz-vm01.xml La commande «list» vous permet d'afficher l'état des machines virtuelles tournant sur l'hôte. virsh # list Id Name State ---------------------------------- 2 slitaz-vm01 running Le domaine s'appelle «slitaz-vm01» et porte la référence «2». Le nom de domaine ou sa référence sont nécessaires pour les commandes de contrôle. La machine virtuelle est démarrée et son écran est déporté en mode vnc (VNC : Virtual Network Computing est un protocole de déport d'écran) Pour l'afficher il suffit d'un client tel que «vncviewer» ou de l'outil «virt-viewer». Ce dernier est compatible libvirt et accepte comme paramètre les nom ou référence de domaine libvirt. Ouvrez un nouveau shell (konsole sous KDE) et lancez la commande suivante pour afficher l'écran de votre machine virtuelle «virt-viewer -c qemu:///system slitaz-vm01». viminal@livecd:~$ virt-viewer -c qemu:///system slitaz-vm01 & Nota : Lancez la commande en arrière plan en suffixant la commande par un «&», afin de récupérer le prompt de commande de votre shell. L'écran de la machine s'affiche et vous pouvez interagir directement dessus. (l'appui simultané sur les touches «ctrl-alt» vous permet de libérer les périphériques d'entrée (clavier / souris). A l'aide de la commande «ps» observez les paramètres de la commande qemu que libvirt a généré pour lancer la machine virtuelle. Comparez aux paramètres de la commande kvm que nous avons utilisé dans la première partie de ce TP. viminal@livecd:~$ ps -edf grep kvm Virsh vous permet de controler la machine. (malheureusement un problème de compatibilité avec la gestion de ACPI par slitaz rend inoppérant le commande «reboot» et «shutdown» seul l'arret brutal «destroy» est reconnu par la machine slitaz). Affichez différentes informations sur l'état de votre machine. TELECOM Lille 1 J. Landru 26 / 39 V1.1-20120221

virsh # dominfo slitaz-vm01.. virsh # domstate slitaz-vm01 virsh # domblkstat slitaz-vm01 hda La commande «shutdown» étant inopérante dans la version actuelle, stoppez brutalement la machine à l'aide de la commande «destroy», puis quittez virsh. virsh # destroy slitaz-vm01 virsh # quit Avant de passer à l'étape suivante, créez le domaine correspondant au deuxième clone de la partie précédente. viminal@livecd:~$ sudo virt-install - name=slitaz-vm02 - ram=256 -disk=/tmp/rootfs-store/vm02-disk.qcow2,device=disk,format=qcow2 -vnc -keymap=fr -video=vga -network=bridge=br0 - accelerate --import La description de la machine virtuelle sous forme de fichier xml est créée (fichier /home/viminal/.libvirt/qemu/slitaz-vm02.xml) et la machine est démarrée. Connectez vous à cette machine à l'aide de l'outil virt-viewer. Ouvrez un nouveau shell (konsole sous KDE) et lancez la commande suivante pour afficher l'écran de votre machine virtuelle «virt-viewer -c qemu:///system slitaz-vm02». viminal@livecd:~$ virt-viewer -c qemu:///system slitaz-vm02 & Nota : Lancez la commande en arrière plan en suffixant la commande par un «&», afin de récupérer le prompt de commande de votre shell. L'écran de la machine s'affiche et vous pouvez interagir directement dessus. (l'appui simultané sur les touches «ctrl-alt» vous permet de libérer les périphériques d'entrée (clavier / souris). Un fois la machine complètement démarrée, stoppez là (Option «Menu Shutdown computer») avant de passer à la suite. Logout 2.6 ) Virt-manager le gestionnaire de machines virtuelles. Virt-manager est une application de gestion de machines virtuelles développée sur libvirt. La majorité des fonctions que l'on a vue dans l'étape précédente a été intégrée dans une interface graphique bien plus intuitive que les outils en mode commande (virt-install et virsh). Cependant la totalité des fonctions n'a pas encore été portée dans l'outil (une TELECOM Lille 1 J. Landru 27 / 39 V1.1-20120221

option comme «--import» de virt-install n'est pas encore disponible lorsque l'on crée une nouvelle VM), mais l'outil est fonctionnel. Avant de démarrer l'outil, redémarrez le daemon libvirtd à l'aide de la commande viminal@livecd:~$ sudo /etc/init.d/libvirtd restart Démarrez virt-manager à l'aide de la commande viminal@livecd:~$ virt-manager Explorez l'interface, pour démarrer les VM clonées, affichez les indicateurs... Créer un nouveau fichier vm03-disk.qcow2 ayant pour référence le pseudo disque vmdisk.img viminal@livecd~$ qemu-img create -f qcow2 -o backing_file=/tmp/rootfs-store/vm-disk.img /tmp/rootfs-store/vm03- disk.qcow2 A l'aide de l'interface virt-manager créer un machine slitaz-vm03 qui pointera sur le fichier qcow2 que vous venez de créer. Attention les configurations par défaut générées par virt-manager lors de la création d'une machine virtuelle ne sont pas reconnues par le système slitaz, il va falloir personnaliser la machine créée pour que le système slitaz puisse démarrer. Enchainer les étapes suivantes : cliquer sur le bouton «create a new virtual machine», (en haut à gauche de l'écran), TELECOM Lille 1 J. Landru 28 / 39 V1.1-20120221

affecter lui le nom de slitaz-vm03, sélectionner le choix «import existing disk image», puis cliquer sur le bouton suivant «forward», sélectionner un fichier existant : choix «browse...» de l'écran intitulé «Provide the existing storage path», puis sélectionner «browse local» et enfin le fichier /tmp/rootfs-store/vm03-disk.qcow2 que vous venez de créer, TELECOM Lille 1 J. Landru 29 / 39 V1.1-20120221

TELECOM Lille 1 J. Landru 30 / 39 V1.1-20120221

TELECOM Lille 1 J. Landru 31 / 39 V1.1-20120221

TELECOM Lille 1 J. Landru 32 / 39 V1.1-20120221

Passer à l'étape suivante (bouton «forward»), affecter «256»Mégaoctets de mémoire à votre VM (au lieu des 1024 initialement affectés par défaut). Puis passer à l'étape suivante (bouton «forward»), TELECOM Lille 1 J. Landru 33 / 39 V1.1-20120221

Attention ne validier pas immédiatement, c'est maintenant que nous allons rendre conforme la configuration matérielle à l'environnement slitaz. Valider le choix «customize configuration before install» et remplacer le choix «no networking» par «spécify shared device name» et séléctionner le «bridge name» br0, TELECOM Lille 1 J. Landru 34 / 39 V1.1-20120221

cliquer sur «finish», TELECOM Lille 1 J. Landru 35 / 39 V1.1-20120221

Dans le nouvel écran, séléctionner le périphérique «disk1», déplier «advanced options» pour séléctionner «storage format» «qcow2», (attention si vous laisser «raw» le disque ne sera pa reconnu et la machine ne pourra pas démarrer, n'oubliez pas d'appliquer vos changement (en cliquant sur le bouton «apply»), TELECOM Lille 1 J. Landru 36 / 39 V1.1-20120221

Séléctionner maintenant le périphérique video et modifier le model «default» en model «vga», si vous laisser le modèle par défaut la carte video ne sera pas reconnue par le système slitaz, n'oubliez pas d'appliquer vos changements (en cliquant sur le bouton «apply»), TELECOM Lille 1 J. Landru 37 / 39 V1.1-20120221

cliquer maintenant sur le bouton intitulé «begin installation», (en haut à gauche de la fenêtre), la machine démarre, après lui avoir affecté une langue, un type de clavier et une dimension d'écran, il ne vous reste plus qu'à lui affecter une adresse IP conforme à notre plan d'adressage (prendre la 192.168.1.103, reporter vous à la procédure déjà utilisée pour les clones slitaz-vm01 et slitaz-vm02 pour cela) TELECOM Lille 1 J. Landru 38 / 39 V1.1-20120221

Observer le contenu du fichier de configuration du clone slitaz-vm03 /home/viminal/.libvirt/qemu/slitaz-vm03.xml généré par libvirt pour virt-manager. Affichez ce contenu du fichier à l'aide de la commande «sudo less». *le fichier, ayant été créé avec les droits super-utilisateur, n'est lisible que par ce dernier. viminal@livecd:~$ sudo less /home/viminal/.libvirt/qemu/slitazvm03.xml Observez comment le différentes caractéristiques de la machine, que vous avez spécifiées à l'aide de «virt-manager», ont été transposées dans le format xml. Notez également que «virt-manager» génère, pour chaque machine créée, une adresse MAC ethernet aléatoire afin de minimiser les risques de collision d'adresse MAC. Attention si vous clonez de nouveau une de machines virtuelles n'oubliez pas d'affecter au clone que vous créez une nouvelle adresse IP sur le réseau 192.168.1.0/24... ----- ooo ----- TELECOM Lille 1 J. Landru 39 / 39 V1.1-20120221