PhilippeLatu inetdoc.net Enseignant - Chargé de mission Systèmes & Réseaux IUT - Université Toulouse III - Paul Sabatier

philippe.latu(at)inetdoc.net

Cet article est à la fois un retour d'expérience et une proposition d'évolution dans l'usage de la virtualisation d'instances de systèmes d'exploitation dans les enseignements pratiques sur ces mêmes systèmes. L'objectif est de faciliter la diffusion et l'usage de la virtualisation auprès des étudiants qui ont quelques difficultés à dépasser le niveau du simple utilisateur. Linux Debian enseignement KVM QEMU switch Travaux pratiques tap VDE Copyright (c) 2000,2012 Philippe Latu. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Copyright (c) 2000,2012 Philippe Latu. Permission est accordée de copier, distribuer et/ou modifier ce document selon les termes de la Licence de Documentation Libre GNU (GNU Free Documentation License), version 1.3 ou toute version ultérieure publiée par la Free Software Foundation ; sans Sections Invariables ; sans Texte de Première de Couverture, et sans Texte de Quatrième de Couverture. Une copie de la présente Licence est incluse dans la section intitulée « Licence de Documentation Libre GNU ». Cet article est écrit avec DocBook XML sur un système Debian GNU/Linux. Il est disponible en version imprimable aux format PDF : vm.pdf. Toutes les commandes utilisées dans ce document ne sont pas spécifiques à une version particulière des systèmes UNIX ou GNU/Linux. C'est la distribution Debian GNU/Linux qui est utilisée pour les tests présentés. Voici une liste des paquets contenant les commandes : procps - The /proc file system utilities kernel-package - A utility for building Linux kernel related Debian packages. fakeroot - Gives a fake root environment. kvm - Full virtualization on x86 hardware qemu - fast processor emulator openvpn - virtual private network daemon vde2 - Virtual Distributed Ethernet Tous les exemples d'exécution des commandes sont précédés d'une invite utilisateur ou prompt spécifique au niveau des droits utilisateurs nécessaires sur le système. Toute commande précédée de l'invite $ ne nécessite aucun privilège particulier et peut être utilisée au niveau utilisateur simple. Toute commande précédée de l'invite # nécessite les privilèges du super utilisateur. Depuis quelques années, j'ai pris l'habitude d'utiliser une instance virtuelle de système d'exploitation pour suivre la même démarche que les étudiants lors des séances de travaux pratiques. La première motivation était d'éviter de massacrer la configuration de mon portable à chaque nouvelle séance. Puis, il est apparu que les synthèses intermédiaires faites en reprenant la démarche «qui aurait dû être suivie» par les étudiants permettait de resynchroniser le groupe et d'obtenir des résultats plus homogènes en fin de séance. Sans démarche de ce genre, une séance de travaux pratiques sur les systèmes informatiques et|ou les réseaux glisse très rapidement vers un bazar incommensurable. En effet, après avoir lu la première question «en diagonale», l'étudiant(e) lambda se jette sur Google et se perd dans les méandres de forums rédigés en mode SMS et aux contenus pour le moins contradictoires et douteux. Bref, on en revient toujours à la problématique classique de l'enseignant moyen : comment faire pour que les étudiants adoptent et suivent des méthodes et démarches réfléchies ? Cette lutte contre l'obscurantisme ambiant est particulièrement ardue. Dans l'esprit de beaucoup d'étudiants, l'informatique est une compilation de «recettes de cuisine» sans relations ni cohérence. Dès lors qu'il s'agit d'approfondir ses connaissances et la maîtrise d'un système, les limites de l'apprentissage par «compilation incohérente» apparaissent très vite et les étudiants les moins motivés décrochent très rapidement. Bien sûr, cet article sur l'utilisation de la virtualisation ne peut absolument pas prétendre apporter une solution à un problème aussi complexe et difficile. L'objectif, très modeste, est d'apporter un moyen supplémentaire d'illustration de la marche à suivre pour traiter un problème en replaçant bien le contexte. Il est aujourd'hui très difficile de «détacher» l'esprit de l'auditoire des commandes utilisées à la console pour faire ressortir le processus traité par ces mêmes commandes. Qu'il s'agisse d'enseignements réseau utilisant des systèmes tels qu'IOS ou JunOS ou d'enseignements systèmes utilisant le Shell, les difficultés sont identiques. À quel niveau se situe le problème à traiter ? Niveau de la modélisation réseau, couche du système d'exploitation, espace mémoire, etc. Quels sont les outils systèmes utilisables à ce niveau ? Configuration d'un protocole, gestionnaire de paquets, analyse de l'occupation mémoire, etc. Quelle est la démarche usuelle de diagnostic ? Table de routage, compteurs de liste de contrôle d'accès, liste des processus actifs, journalisation système, etc. Pour aller un peu plus loin dans l'illustration des méthodes, je souhaite dépasser le stade de la démonstration sur le portable de l'enseignant et fournir aux étudiants des images d'instances de systèmes en fin de séance. Il ne s'agit pas de fournir une solution corrigée ou un produit fini mais plutôt une photo d'un état intermédiaire dans la séance de travaux pratiques. Il devient ainsi possible de proposer aux étudiants de reprendre, non pas la totalité des questions de la séance, mais la partie qui a posé le plus de difficultés. Voici donc, dans l'état actuel de la réflexion, les choix techniques que j'ai fait pour répondre aux objectifs. À l'heure actuelle, il existe deux grandes approches de la virtualisation. Une première méthode, appelée paravirtualisation, suppose que le noyau du système d'exploitation invité soit légèrement modifié pour être exécuté sous forme virtualisée. L'objectif de cette technique est d'offrir un accès quasi identique aux ressources matérielles (mémoire et entrées/sorties) entre système hôte et système invité. Si cet objectif est atteint, les performances du système virtualisé sont vraiment très proches de celles du matériel sur lequel il est exécuté. Le principal obstacle au développement ce cette technique réside justement dans la modification du noyau du système invité. Si le système à virtualiser ne dispose pas de fonctions dédiées à la paravirtualisation dans son noyau, cette technique est inutilisable et la seule solution de virtualisation consiste à utiliser une émulation complète du matériel. La seconde méthode, appelée virtualisation complète, permet d'exécuter le système d'exploitation invité de manière native sans modification. Avec cette technique, la virtualisation n'a aucun impact sur l'exécution du noyau du système virtualisé. En revanche, la virtualisation complète sacrifie les performances au prix de la compatibilité. En effet, il est plus difficile d'obtenir de bonnes performances lorsque le système invité ne participe pas au processus de virtualisation et doit traverser une ou plusieurs couches d'émulation avant d'accéder aux ressources matérielles. Côté matériel, les développements récents sur les processeurs ont tendance à diminuer les écarts de performances entre paravirtualisation et virtualisation complète. Qu'il s'agisse d'Intel (VT : Intel® Virtualization Technology) ou d'AMD (AMD-V : Industry Leading Virtualization Platform Efficiency) les derniers processeurs disposent de fonctions matérielles pour la virtualisation. Avec le noyau Linux, l'objectif de la solution Kernel Based Virtual Machine ou KVM est d'ajouter des capacités de virtualisation à un noyau standard. Il est ainsi possible de tirer parti de toutes les fonctions de réglage fin déjà intégrées au noyau et de bénéficier des nouveaux avantages apportés par les environnements virtualisés. Avec le modèle KVM, chaque machine virtuelle est un processus standard du noyau Linux géré par l'ordonnanceur (scheduler). Un processus normal de système GNU/Linux peut être exécuté selon deux modes : noyau (kernelspace) ou utilisateur (userspace). Le modèle KVM ajoute un troisième mode : le mode invité qui possède ses propres modes noyau et utilisateur. KVM dans le noyau Linux KVM dans le noyau Linux - vue complète Le modèle de virtualisation KVM comprend deux composants. Un pilote de périphérique pour gérer le matériel virtualisé. Les fonctions de ce pilote sont disponibles via le fichier spécial d'interface de type caractère /dev/kvm. Cette partie noyau (kernelspace) de la solution est présentée à la . Un logiciel utilisateur pour émuler le matériel d'un PC. Cette partie utilisateur (userspace) est une version légèrement modifiée des outils QEMU. Elle est présentée plus en détails à la . Côté paravirtualisation, ce sont les fonctions virtio publiées dans la version 2.6.25 du noyau Linux qui permettent d'utiliser des canaux de communication dédiés entre instances de machines virtuelles et système hôte. Depuis la sortie de la version stable baptisée Lenny de la distribution Debian GNU/Linux, ces fonctions sont disponibles dans les paquets de noyau. Aucune manipulation n'est donc nécessaire pour bénéficier de la paravirtualisation avec une instance de système Debian GNU/Linux. De plus, ces bibliothèques sont utilisables indifféremment avec un système hôte dont le processeur possède des extensions matérielles exploitées avec l'application utilisateur KVM ou avec un système hôte qui n'en possède pas et sur lequel on exploite l'application utilisateur QEMU. Pendant longtemps, j'ai utilisé les outils VMware. Cette solution, séduisante au premier abord, pose un certain nombre de problèmes dans le temps. Tout d'abord, ces outils propriétaires sont «désynchronisés» par rapport aux développements du noyau Linux. Régulièrement, je me suis retrouvé dans l'incapacité d'utiliser les instances de machines virtuelles pendant une ou deux semaines. Il est nécessaire de repasser par des compilations après application de correctifs (patches) intermédiaires. Ensuite, les solutions libres et synchrones avec les évolutions de l'ensemble de la chaîne GNU/Linux se sont développées et ont gagné en maturité. Même si ce type de choix est toujours discutable, j'ai jeté mon dévolu sur le couple QEMU/KVM. KVM Kernel-based Virtual Machine Kernel Based Virtual Machine est devenue rapidement la solution de virtualisation de référence pour Linux. Elle est basée sur les architectures Intel baptisées Intel VT ou les architectures AMD baptisées AMD-V. Ces deux familles de processeurs possèdent les extensions matérielles de virtualisation. Un module du noyau Linux fournit le cœur de virtualisation et un module spécifique dépendant du processeur (kvm-intel.ko ou kvm-amd.ko) active les fonctions matérielles. QEMU QEMU open source machine emulator est un émulateur machine générique. Il peut exécuter des instances de systèmes d'exploitation (OSes) et des programmes faits pour une architecture processeur particulière (carte mère ARM par exemple) sur une machine hôte d'architecture différente (votre propre PC par exemple). En utilisant la traduction dynamique, QEMU donne de bonnes performances. QEMU est la solution de virtualisation à utiliser si le processeur de système hôte ne possède pas d'extension matérielle spécifique à la virtualisation. Les développements de ces deux outils distincts progressent en parallèle et ils utilisent le même jeu d'options de configuration. La présentation de ces 2 outils complémentaires introduit la distinction entre les processeurs possédant les extensions de virtualisation ou non. Pour identifier les caractéristiques des processeurs avec un système hôte GNU/Linux, on utilise les informations fournies dans l'arborescence /proc. Si le seul système d'exploitation installé sur la machine hôte est de type Windows, il est toujours possible de lancer la machine en utilisant un live CD de type KNOPPIX pour effectuer la même opération. Suivant le résultat de la commande suivante, on sait si le processeur peut utiliser la solution KVM ou non. $ egrep '(vmx|svm)' /proc/cpuinfo Si la commande ne donne aucun résultat, le processeur ne possède pas d'extension de virtualisation et seule la solution QEMU est utilisable. Si le résultat donne une ou plusieurs lignes (suivant le nombre de cœurs du processeur) débutant par flags, la solution KVM est utilisable avec les outils QEMU. Comme on l'a vu dans la , cette solution de virtualisation ne peut être utilisée qu'avec un processeur possédant les extensions matérielles nécessaires. Voici un exemple d'identification sur un processeur Intel du type : Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz. $ egrep '(vmx|svm)' /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr lahf_lm Pour exploiter les extensions matérielles du processeur, il faut sélectionner les modules du noyau Linux à utiliser. Liste des options de virtualisation KVM du noyau Linux Liste des options de virtualisation KVM du noyau Linux - vue complète Pour construire un paquet Debian de noyau Linux avec les options ci-dessus, on passe par les étapes rituelles suivantes. $ cd /usr/src $ wget http://www.eu.kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.3.tar.bz2 $ tar xf linux-2.6.25.3.tar.bz2 $ ln -s linux-2.6.25.3 linux $ cd linux $ cp /boot/config-2.6.25.2 .config $ make menuconfig $ make-kpkg --rootcmd fakeroot --initrd kernel_image Si l'utilisateur normal fait partie du groupe système src, il a les droits suffisants pour construire un paquet de noyau Linux. C'est la raison pour laquelle l'invite utilisateur (prompt) est le caractère '$' pour toutes les opérations suivantes. Avant d'accéder aux menus de configuration des fonctions du noyau Linux, il est préférable de travailler à partir d'une configuration existante et fonctionnelle. On recopie donc la configuration de la version précédente du noyau. Normalement, c'est celle du noyau en cours d'exécution. Accès aux menus de configuration. Voir la copie d'écran ci-dessus. Les outils fakeroot et make-kpkg servent respectivement à utiliser une «fausse» arborescence racine à partir des droits d'un utilisateur normal et à construire le paquet de noyau après avoir compilé la partie monolithique et les modules. L'installation du nouveau noyau doit se faire avec les droits super utilisateur. # dpkg -i linux-image-2.6.25.3_2.6.25.3-10.00.Custom_amd64.deb Sélection du paquet linux-image-2.6.25.3 précédemment désélectionné. (Lecture de la base de données... 249991 fichiers et répertoires déjà installés.) Dépaquetage de linux-image-2.6.25.3 \ (à partir de linux-image-2.6.25.3_2.6.25.3-10.00.Custom_amd64.deb) ... Done. Paramétrage de linux-image-2.6.25.3 (2.6.25.3-10.00.Custom) ... Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Running postinst hook script update-grub. Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... Found kernel: //vmlinuz-2.6.25.3 Found kernel: //vmlinuz-2.6.25.2 Updating /boot/grub/menu.lst ... done Une fois le nouveau noyau installé et le système réinitialisé, on peut valider le chargement des modules si les scripts d'initialisation assurent cette fonction. Par exemple, la distribution Debian GNU/Linux fournit un paquet kvm qui contient un script assurant le chargement du module approprié au démarrage du système hôte. $ lsmod |grep kvm kvm_intel 38016 3 kvm 214257 1 kvm_intel On constate que les modules sont effectivement chargés en mémoire à l'aide d'un script que l'on peut identifier. $ dpkg -L qemu-kvm | grep init.d/ /etc/init.d/qemu-kvm Si toutefois, le chargement ne se fait pas automatiquement, on peut procéder au chargement manuel des modules de virtualisation KVM et valider l'accès aux fonctions matérielles du processeur. # uname -ar Linux typhoon 2.6.25.3 #1 SMP PREEMPT Sat May 10 18:23:31 CEST 2008 x86_64 GNU/Linux # modprobe -v kvm-intel insmod /lib/modules/2.6.25.3/kernel/arch/x86/kvm/kvm.ko insmod /lib/modules/2.6.25.3/kernel/arch/x86/kvm/kvm-intel.ko Maintenant que les fonctions de virtualisation KVM sont en place, on peut passer à la création d'une instance de système d'exploitation. Voir la . Comme on l'a vu dans la , ces bibliothèques permettent à une instance de machine virtualisée d'utiliser des canaux de communications particuliers vers le matériel du système hôte. Parmi ces canaux, on trouve les accès mémoire, disque, horloge temps réel et réseau. Avec la publication de la version stable de la distribution Debian GNU/Linux baptisée Lenny, ces bibliothèques sont disponibles dans les paquets de noyau. C'est donc dans l'arborescence des modules du paquet que l'on effectue la recherche. On commence par identifier le paquet de noyau correspondant à la distribution. $ dpkg -l linux-image* | grep ^ii ii linux-image-2.6-amd64 2.6.32+28 Linux 2.6 for 64-bit PCs (meta-package) ii linux-image-2.6.32-5-amd64 2.6.32-27 Linux 2.6.32 for 64-bit PCs En fonction de la version identifiée, on recherche les modules dans son arborescence. $ find /lib/modules/2.6.32-5-amd64/ -type f -name "*virtio*" /lib/modules/2.6.32-5-amd64/kernel/net/9p/9pnet_virtio.ko /lib/modules/2.6.32-5-amd64/kernel/drivers/net/virtio_net.ko /lib/modules/2.6.32-5-amd64/kernel/drivers/virtio/virtio_pci.ko /lib/modules/2.6.32-5-amd64/kernel/drivers/virtio/virtio_balloon.ko /lib/modules/2.6.32-5-amd64/kernel/drivers/virtio/virtio_ring.ko /lib/modules/2.6.32-5-amd64/kernel/drivers/virtio/virtio.ko /lib/modules/2.6.32-5-amd64/kernel/drivers/block/virtio_blk.ko /lib/modules/2.6.32-5-amd64/kernel/drivers/char/hw_random/virtio-rng.ko /lib/modules/2.6.32-5-amd64/kernel/drivers/char/virtio_console.ko Lorsque ce noyau est exécuté sur une instance de machine virtuelle, ces modules sont utilisés et améliorent considérablement les performances. Les informations données dans cette section anticipent les résultats présentés dans les suivantes sachant que l'on ne peut caractériser l'utilisation des modules qu'à partir d'une instance de machine virtuelle. Comme on l'a dit précédemment, ces bibliothèques constituent des canaux de communication avec le matériel du système hôte. Elles ont donc un effet sur la représentation du matériel émulé au niveau du système virtualisé. À titre d'exemple, voici la liste des périphériques «visibles» sur le bus PCI d'une instance de système virtuel. $ lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device 00:04.0 SCSI storage controller: Red Hat, Inc Virtio block device Dans la liste ci-dessus, on reconnaît trois périphériques référencés Virtio dont le gestionnaire mémoire et le contrôleur réseau. Sur le même système, on peut lister les modules chargés en mémoire relatifs aux bibliothèques. $ lsmod | grep virtio virtio_blk 12775 3 virtio_net 17496 0 virtio_pci 13207 0 virtio_ring 12793 3 virtio_blk,virtio_net,virtio_pci virtio 13093 3 virtio_blk,virtio_net,virtio_pci Cette liste correspond aux fonctionnalités utilisées par le système virtuel relativement au catalogue donné dans la section précédente. Toutes les opérations présentées dans cette section utilisent le répertoire utilisateur ~/vm/ dans lequel sont stockées les images de disques virtuels. Dans le but de faciliter la diffusion des images de machines virtuelles auprès des étudiants, ce répertoire peut appartenir à l'arborescence du serveur Web apache du portable de l'enseignant. De cette façon, il est possible diffuser instantanément des snapshots en cours de séance de travaux pratiques. Dans ce cas, le véritable répertoire de stockage des images de machines virtuelles est /var/www/vm/ et ~/vm/ est un lien symbolique qui pointe dessus. Sachant que les modules de virtualisation appartenant au noyau Linux sont chargés en mémoire, il faut maintenant connaître la liste des outils nécessaires à la création des instances de machines virtuelles. Le paquet associé au gestionnaire de virtualisation KVM fait partie de la collection QEMU. Plusieurs manipulations sont possibles pour connaître l'état des paquets installés sur un système. $ aptitude search '~ikvm' i qemu-kvm - Full virtualization on x86 hardware $ dpkg -l *kvm* | grep ^ii ii qemu-kvm 0.13.0+dfsg-1 Full virtualization on x86 hardware Ce paquet kvm fournit le processus d'émulation d'architecture x86 avec le support des extensions matérielles : Intel VT et AMD SVM. Il contient aussi contient les éléments d'émulation des périphériques de carte mère : contrôleur PCI, carte vidéo, cartes réseau, claviers de différentes nationalités, etc. On commence par créer une image de disque virtuel qui servira de support au système de fichiers de la nouvelle instance de système d'exploitation. :~/vm$ qemu-img create vm0-debian-stable-amd64.raw -f raw 4G Formatting 'vm0-debian-stable-amd64.raw', fmt=raw, size=4194304 kB Le format d'image créé à l'aide de l'instruction ci-dessus est baptisé raw. Il s'agit d'un format simple, utilisé par défaut, sur lequel seuls les secteurs écrits entraînent une réservation d'espace si le système de fichiers supporte un tel mode de fonctionnement. Ce choix de format peut être modifié par la suite puisqu'il est toujours possible de convertir une image d'un format à un autre après coup. On utilise cette image disque pour lancer le processus d'installation de la machine virtuelle. :~/vm$ kvm \ -name install-example \ -m 512 \ -rtc base=localtime,clock=host \ -drive file=vm0-debian-stable-amd64.raw,if=virtio,media=disk,boot=off \ -k fr \ -usb -usbdevice tablet \ -cdrom ~/iso.images/debian-501-amd64-DVD-1.iso \ -boot d Appel de l'émulateur PC KVM. Son rôle est de fournir une liste type des périphériques que l'on trouve sur une carte mère de PC. Cet émulateur se comporte exactement comme l'émulateur QEMU. La liste des périphériques matériels émulés est disponible à la section QEMU PC System emulator de la documentation officielle QEMU. Quantité de mémoire vive (RAM) allouée à la machine virtuelle. Paramétrage des sources de temps. Dans cet exemple, l'horloge temps réel (RTC), définie par le paramètre base, utilise le temps défini au niveau du système hôte. De la même façon, la date est définie à partir du système hôte via le paramètres clock. Correspondance entre unité de disque dur virtuelle et image disque système. Dans cet exemple, le périphérique hda désigne un disque dur IDE. Désignation du modèle de clavier à utiliser. Ici, il s'agit du clavier AZERTY français. Gestion de la capture automatique du curseur de la souris. Avec ce modèle de «tablette USB», il n'est plus nécessaire d'utiliser la séquence de touches Alt+Ctrl pour basculer entre la fenêtre de l'instance virtuelle et celles du système hôte. Correspondance entre lecteur CD/DVD et image ISO du DVD d'installation de la distribution Debian GNU/Linux. Désignation de l'unité de démarrage. Comme il s'agit d'une première installation, c'est le lecteur CD/DVD qui est utilisé pour accéder à l'image ISO d'installation. Par la suite, le même traitement peu être réalisé en utilisant le script startup.sh proposé dans la . :~/vm$ ./scripts/startup.sh 512 2 \ vm0-debian-stable-amd64.raw \ -cdrom ~/iso.images/debian-501-amd64-DVD-1.iso \ -boot d Après l'initialisation de la machine virtuelle, le processus d'installation classique démarre. Les opérations suivantes sont communes aux deux solutions de virtualisation. Les éléments sur le partitionnement disque sont donnés dans la . Les opérations présentées ici utilisent la même arborescence que dans la section sur la solution KVM. Voir la note sur la création d'une machine virtuelle avec KVM. Sur un système hôte dont le processeur ne possède pas d'extension matérielle dédiée à la virtualisation, on se limite à l'utilisation de l'émulateur QEMU. Dans ce contexte, le paquet qemu est le principal outil à utiliser. $ dpkg -l qemu* | grep ^ii ii qemu 0.11.1-1 fast processor emulator ii qemu-kvm 0.11.0+dfsg-1 Full virtualization on x86 hardware ii qemu-system 0.11.1-1 QEMU full system emulation binaries ii qemu-user 0.11.1-1 QEMU user mode emulation binaries ii qemu-utils 0.11.1-1 QEMU utilities Les principales dépendances sont relatives à l'émulation PC avec les paquets BIOS : bochbios et vgabios. La création du fichier image correspondant au volume de stockage utilisé par une instance de machine virtuelle se fait à l'aide de la même commande : qemu-img quel que soit l'émulateur utilisé par la suite. On répète ci-dessous la même opération que celle présentée à la . :~/vm$ qemu-img create vm0-debian-stable-i386-base.raw -f raw 4G Formatting 'vm0-debian-stable-i386-base.raw', fmt=raw, size=4194304 kB :~/vm$ ls -sAh vm0-debian-stable-i386-base.raw 4G vm0-debian-stable-i386-base.raw On utilise l'image disque pour lancer le processus d'installation de la machine virtuelle. :~/vm$ qemu \ -k fr \ -usbdevice tablet \ -drive file=vm0-debian-stable-i386-base.raw,if=virtio,media=disk,boot=off \ -cdrom ~/iso.images/debian-501-i386-CD-1.iso \ -boot d \ -m 384 Appel de l'émulateur PC QEMU. Son rôle est de fournir une liste type des périphériques que l'on trouve sur une carte mère de PC. Cette liste est disponible à la section QEMU PC System emulator de la documentation officielle QEMU. Désignation du modèle de clavier à utiliser. Ici, il s'agit du clavier AZERTY français. Gestion de la capture automatique du curseur de la souris. Avec ce modèle de «tablette USB», il n'est plus nécessaire d'utiliser la séquence de touches Alt+Ctrl pour basculer entre la fenêtre de l'instance virtuelle et celles du système hôte. Correspondance entre unité de disque dur virtuelle et image disque système. Dans cet exemple, le périphérique hda désigne un disque dur IDE. Correspondance entre lecteur CD et image ISO du CD d'installation de la distribution Debian GNU/Linux. Désignation de l'unité de démarrage : le lecteur CD pour utiliser le CD d'installation. Quantité de mémoire vive (RAM) allouée à la machine virtuelle. Après l'initialisation de la machine virtuelle, le processus d'installation classique démarre. Écran installation Debian GNU/Linux Écran installation Debian GNU/Linux - vue complète Une fois le processus d'installation lancé, les étapes de sélection se suivent : langue, clavier, choix des composants, configuration automatique du réseau, nom d'hôte et partitionnement. Il est vivement conseillé d'utiliser le gestionnaire de volumes logiques LVM pour pouvoir faire évoluer l'image système par la suite. En publiant des images disque de taille limitée, l'objectif est justement de «provoquer» la saturation de l'espace disque pour pousser les étudiants à se familiariser avec l'utilisation des outils LVM de gestion du stockage. Une fois l'installation achevée, on obtient l'occupation disque suivante. On constate qu'il reste une marge d'espace disque conséquente ; ce qui permettra d'installer quantité de services supplémentaires avant de devoir étendre l'espace de stockage. $ df -h Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/mapper/vm--debian-root 473M 112M 338M 25% / tmpfs 506M 0 506M 0% /lib/init/rw udev 10M 92K 10M 1% /dev tmpfs 506M 0 506M 0% /dev/shm /dev/hda1 228M 16M 200M 8% /boot /dev/mapper/vm--debian-home 473M 11M 438M 3% /home /dev/mapper/vm--debian-usr 1,9G 318M 1,5G 18% /usr /dev/mapper/vm--debian-var 548M 157M 364M 31% /var Cette section est commune aux deux solutions de virtualisation QEMU et KVM. Il s'agit d'un catalogue de quelques trucs et astuces permettant d'optimiser l'usage d'une instance virtuelle de système d'exploitation. Pour optimiser la gestion de paquets avec APT sur une machine virtuelle Debian GNU/Linux on essaie de limiter au maximum l'occupation disque de façon à donner un maximum d'espace aux services Internet dans l'arborescence /var. # aptitude clean Il est inutile de conserver les fichiers .deb correspondant aux paquets installés sur le système virtuel. La commande # aptitude clean sert justement à nettoyer l'arborescence /var/cache/apt. # aptitude purge $(deborphan) La commande deborphan appartenant au paquet du même nom recherche les paquets orphelins installé sur le système. Les paquets trouvés ne sont pas nécessaires au fonctionnement des services installés ; on peut donc les supprimer sans problème pour gagner de la place disque. Le résultat de la commande suivante montre que le «ménage» a été fait. # aptitude purge $(deborphan) Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Lecture de l'information d'état étendu Initialisation de l'état des paquets... Fait Aucun paquet ne va être installé, mis à jour ou enlevé. 0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de télécharger 0o d'archives. Après dépaquetage, 0o seront utilisés. Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Lecture de l'information d'état étendu Initialisation de l'état des paquets... Fait # localepurge La commande localepurge appartenant au paquet du même nom. Elle sert à effacer tous les fichiers de «localisation» (langues étrangères) inutiles sur le disque. Elle est appelée automatiquement à chaque opération de gestion de paquets avec dselect, apt-get ou aptitude. La fin du fichier de configuration /etc/locale.nopurge répertorie les paramètres des fichiers de localisation à conserver. # tail /etc/locale.nopurge ##################################################### # Following locales won't be deleted from this system # after package installations done with apt-get(8): en fr fr_FR.UTF-8 Transparent proxy Service Mandataire L'utilisation du gestionnaire de paquets peut poser problème lorsque le système hôte se trouve derrière un service mandataire ou proxy transparent. Dans ce cas, il faut compléter la configuration du gestionnaire de paquets sur chaque instance de système virtuel en ajoutant un fichier dans le répertoire /etc/apt/apt.conf.d/. # cat /etc/apt/apt.conf.d/10proxy Acquire::http::No-Cache "true"; Acquire::http::Max-Age "0"; Duplication du jeu de paquets entre systèmes aptitude-create-state-bundle aptitude-run-state-bundle Pour dupliquer le jeu de paquets installés entre instances système, il est possible de créer un fichier image de l'état d'une installation. Cette technique permet de transférer la liste des paquets installés entre architectures différentes. Le transfert le plus courant consiste à passer d'une architecture 32 bits ou i386 à une architecture 64 bits ou amd64. Côté système source, celui qui détient le jeu de référence, on utilise la commande aptitude-create-state-bundle. # aptitude-create-state-bundle selections.bz2 # exit etu@vm:~$ logout Connection to 192.0.2.2 closed. :~/vm$ scp etu@192.0.2.2:~/selections.bz2 . etu@192.0.2.2's password: selections.bz2 100% 30MB 15.0MB/s 00:02 Côté système destination, celui sur lequel on doit appliquer le jeu de référence pour compléter sa liste de paquets installés, on utilise la commande aptitude-run-state-bundle. :~/vm$ ./scripts/startup.sh vm0-debian-stable-amd64-base.raw 384 2 Adresse MAC : 52:54:00:12:34:02 et N° port 2 :~/vm$ scp selections.bz2 etu@192.0.2.2:~ etu@192.0.2.2's password: selections.bz2 100% 30MB 29.9MB/s 00:01 :~/vm$ ssh etu@192.0.2.2 etu@192.0.2.2's password: etu@vm:~$ su Mot de passe : vm:/home/etu# aptitude-run-state-bundle selections.bz2 vm:/home/etu# aptitude -u Que l'on accède à une instance de système virtualisé via le terminal d'exécution, VNC ou SSH, il est important de disposer d'un jeu de caractères et d'un affichage cohérent. Terminal d'exécution gpm Le paquet gpm permet d'utiliser la souris en mode console pour effectuer les opérations du type copier/coller. console-data Avec une instance stable (Lenny) de système virtuel sans interface graphique, c'est le paquet console-data qui permet de gérer les codes de touches clavier, les jeux de caractères et les polices en mode console. La reconfiguration du paquet console-data avec la commande # dpkg-reconfigure -plow console-data permet de sélectionner les options suivantes : Politique de gestion des codages clavier : Choisir un codage clavier pour votre architecture Disposition générale du clavier : azerty Disposition du clavier : French Variante du clavier : Same as X11 (latin 9) console-setup Dans le cas d'une instance testing ou unstable de système virtuel avec ou sans interface graphique, c'est le paquet console-setup qui gère les codes de touches clavier, les jeux de caractères et les polices en mode console. La reconfiguration du paquet console-setup avec la commande # dpkg-reconfigure -plow console-setup permet de sélectionner les options suivantes : Modèle du clavier : Generic 105-key (Intl) PC Origine du clavier : France Disposition du clavier : France - (Legacy) Alternative Touche de remplacement d'AltGr : Touche Alt de droite Touche « compose » : Pas de touche « compose » Codage de la console : UTF-8 Jeu de caractères devant être pris en charge par la police de la console : # latin1 et latin5 : langues de l'Europe de l'ouest et turc Police de caractères pour la console : Fixed Taille de la police : 18 Consoles virtuelles utilisées : /dev/tty[1-6] La gestion de l'interface graphique d'une instance de système virtualisé ne peut prétendre atteindre les mêmes performances que sur un système hôte. En effet, sur un système non virtualisé le graphisme utilise les ressources d'un composant spécifique baptisé Graphics Processing Unit ou GPU. La virtualisation implique l'émulation d'un composant GPU et vu la complexité des traitements assurés par ces composants, la tâche est particulièrement ardue. À l'heure actuelle, on ne trouve pas d'émulation de composant interfacé sur bus PCI Express dans les solutions libres. Pour corser un peu plus la situation, les bibliothèques X.Org sont en pleine mutation au moment de la rédaction de ces lignes. Historiquement, le serveur graphique procède lui-même à l'inventaire des fonctions graphiques offertes par le GPU présent sur le système. C'est le mode de fonctionnement que l'on retrouve sur la version stable de la distribution Debian GNU/Linux. Avec les versions les plus récentes des bibliothèques X.org, le logiciel serveur ne procède plus à un inventaire autonome et doit s'appuyer sur d'autres outils de façon à réagir à chaud aux modifications de configuration matérielle : connexion/déconnexion de périphériques. Comme les solutions KVM et QEMU partagent les mêmes fonctions d'émulation, elles proposent la même carte graphique très basique. $ lspci |grep VGA 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 La lecture de la documentation du composant CL-GD5446 indique clairement que la meilleure qualité d'affichage est obtenue pour une résolution de 1024x768. Toute augmentation de cette résolution se fait au détriment de la profondeur de couleur. Pour cette raison, nous ne chercherons pas à dépasser la résolution nominale du composant émulé. À titre d'exemple, voici une copie du fichier de configuration sur une instance de système virtuel Debian/testing, un extrait de l'inventaire des caractéristiques du composant graphique identifiées ainsi que deux copies d'écran de l'interface KDE 4.2. Fichier de configuration principal X.Org : /etc/X11/xorg.conf. Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "fr" Option "XkbVariant" "latin9" Option "XkbOptions" "lv3:ralt_switch" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" EndSection Section "Device" Identifier "Configured Video Device" EndSection Section "Monitor" Identifier "Configured Monitor" HorizSync 30 - 90 VertRefresh 50 - 160 EndSection Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1024x768" "800x600" EndSubSection EndSection Extraits du journal d'exécution du serveur graphique. # less /var/log/Xorg.0.log <snip/> (--) PCI:*(0:2:0) Cirrus Logic GD 5446 rev 0, Mem @ 0xf0000000/25, 0xf2000000/12 <snip/> (==) CIRRUS(0): Write-combining range (0xf0000000,0x100000) (--) CIRRUS(0): Memory Config reg 1 is 0x98 (--) CIRRUS(0): Memory Config reg 2 is 0x20 (--) CIRRUS(0): VideoRAM: 4096 kByte (==) CIRRUS(0): Min pixel clock is 12 MHz (--) CIRRUS(0): Max pixel clock is 85 MHz (II) CIRRUS(0): Configured Monitor: Using hsync range of 30.00-90.00 kHz (II) CIRRUS(0): Configured Monitor: Using vrefresh range of 50.00-160.00 Hz (II) CIRRUS(0): Clock range: 12.00 to 85.50 MHz <snip/> (--) CIRRUS(0): Virtual size is 1024x768 (pitch 1024) (**) CIRRUS(0): *Default mode "1024x768": 78.8 MHz, 60.0 kHz, 75.0 Hz (II) CIRRUS(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) Copies d'écran de l'interface graphique sur une instance de machine virtuelle Debian/testing. Gestionnaire de connexion KDE 4.2 Gestionnaire de connexion KDE 4.2 - copie d'écran Gestionnaire de fenêtre KDE 4.2 Gestionnaire de fenêtre KDE 4.2 - copie d'écran Une autre solution consiste à utiliser le paramètre -vga lors de l'initialisation de l'instance de machine virtuelle en indiquant une autre émulation graphique. L'émulation d'adaptateur compatible VMWare SVGA-II offre un panel de résolutions plus important. Relativement à l'émulation de la carte Cirrus CL-GD5446 présentée ci-dessus, la configuration est considérablement simplifiée puisqu'il n'est plus nécessaire d'utiliser un fichier /etc/X11/xorg.conf paramétré manuellement. La reconnaissance automatisée du composant graphique fonctionne directement. Pour administrer des systèmes à distance, le protocole SSH est le mode de connexion universel. Dans le contexte particulier de l'administration des instances de systèmes virtuels, une même image système avec une même clé d'hôte RSA est dupliquée autant de fois que nécessaire. On se trouve rapidement confronté aux traditionnels messages d'alertes sur l'usurpation de cette clé d'hôte lorsque l'on accès aux instances virtuelles depuis le système hôte. On peut configurer le client SSH du système hôte de façon à ne pas vérifier «l'identité», c'est à dire la clé d'hôte RSA, des instances de systèmes virtualisées. La documentation complète sur la configuration du client SSH est fournie dans les pages de manuels : $ man ssh_config. Voici un extrait de fichier ~/.ssh/config qui désactive les contrôles pour tous les hôtes dont les adresses IP correspondent au masque 192.0.*. Host 192.0.* CheckHostIP no StrictHostKeyChecking no UserKnownHostsFile=/dev/null L'énorme avantage de l'utilisation du gestionnaire de volume logique LVM avec les images disques de machine virtuelle, c'est que l'on peut manipuler la capacité de stockage après installation. Dans le cas présent, les images disques ont été dimensionnées à minima pour faciliter le téléchargement à partir du serveur Web de l'infrastructure de travaux pratiques. Il est donc important de pouvoir étendre la capacité d'une instance système après copie sur le système hôte. Du point de vue pédagogique, c'est aussi l'occasion de se familiariser avec les fonctionnalités offertes par les outils LVM. Ces outils sont devenus indispensables dans la gestion de la capacité de stockage d'un serveur aujourd'hui. Voici un exemple d'extension de la capacité de stockage d'une image de machine virtuelle Debian/testing avec interface graphique. À partir d'un volume de stockage initial de 4Go on ajoute 8Go en répartissant cette extension entre les volumes logiques de l'arborescence système. On commence par identifier les caractéristiques du fichier image du système avant extension. $ ls -sh vm0-debian-testing-amd64-X11.qcow2 2,3G vm0-debian-testing-amd64-X11.qcow2 Une fois l'instance de système virtuel lancée, on obtient l'occupation disque suivante. etu@vm:~$ df -h Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/mapper/vm--debian-root 473M 105M 344M 24% / tmpfs 503M 0 503M 0% /lib/init/rw udev 10M 148K 9,9M 2% /dev tmpfs 503M 0 503M 0% /dev/shm /dev/hda1 228M 20M 197M 9% /boot /dev/mapper/vm--debian-home 473M 14M 435M 3% /home /dev/mapper/vm--debian-usr 1,9G 1,2G 586M 68% /usr /dev/mapper/vm--debian-var 595M 235M 330M 42% /var Toujours à partir de la même instance la table des partitions est la suivante. # fdisk -l /dev/hda Disk /dev/hda: 4294 MB, 4294967296 bytes 255 heads, 63 sectors/track, 522 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000162 Device Boot Start End Blocks Id System /dev/hda1 * 1 31 248976 83 Linux /dev/hda2 32 522 3943957+ 8e Linux LVM Avant de passer à l'opération d'extension, on effectue une conversion du fichier image au format «brut» non compressé ou format raw. $ qemu-img convert -O raw vm0-debian-testing-amd64-X11.qcow2 \ vm0-debian-testing-amd64-X11-extended.raw $ ls -sh vm0-debian-testing-amd64-X11* 2,1G vm0-debian-testing-amd64-X11-extended.raw 2,3G vm0-debian-testing-amd64-X11.qcow2 On procède enfin à l'augmentation de capacité à l'aide de la commande dd. On passe d'un fichier image d'une capacité de 4Go à 12Go en ajoutant 8Go. $ dd if=/dev/zero of=vm0-debian-testing-amd64-X11-extended.raw seek=12288 obs=1MB count=0 0+0 enregistrements lus 0+0 enregistrements écrits 0 octet (0 B) copié, 3,3943e-05 s, 0,0 kB/s Pour terminer cette extension d'image disque, on reconvertit le fichier image au format compressé qcow2. $ qemu-img convert -O qcow2 vm0-debian-testing-amd64-X11-extended.raw \ vm0-debian-testing-amd64-X11-extended.qcow2 $ ls -lAh vm0-debian-testing-amd64-X11* -rw-r--r-- 1 phil phil 2,1G mai 24 18:10 vm0-debian-testing-amd64-X11-extended.qcow2 -rw-r--r-- 1 phil phil 12G mai 24 16:23 vm0-debian-testing-amd64-X11-extended.raw -rw-r--r-- 1 phil phil 2,3G mai 24 18:08 vm0-debian-testing-amd64-X11.qcow2 Le fichier image au format brut (raw) est maintenant inutile et peut être supprimé sans problème. En utilisant l'image système étendue générée ci-avant, on fait apparaître l'espace disponible en affichant l'état des partitions. # fdisk -l /dev/hda Disk /dev/hda: 12.2 GB, 12288000000 bytes 255 heads, 63 sectors/track, 1493 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000162 Device Boot Start End Blocks Id System /dev/hda1 * 1 31 248976 83 Linux /dev/hda2 32 522 3943957+ 8e Linux LVM On remarque que l'espace total a bien été augmenté et qu'aucune partition n'est disponible. Il faut donc créer une nouvelle partition correspondant à l'espace libre. # fdisk /dev/hda The number of cylinders for this disk is set to 1493. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): p Disk /dev/hda: 12.2 GB, 12288000000 bytes 255 heads, 63 sectors/track, 1493 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000162 Device Boot Start End Blocks Id System /dev/hda1 * 1 31 248976 83 Linux /dev/hda2 32 522 3943957+ 8e Linux LVM Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 3 First cylinder (523-1493, default 523): Using default value 523 Last cylinder or +size or +sizeM or +sizeK (523-1493, default 1493): Using default value 1493 Command (m for help): t Partition number (1-4): 3 Hex code (type L to list codes): 8e Changed system type of partition 3 to 8e (Linux LVM) Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 16: Périphérique ou ressource occupé. The kernel still uses the old table. The new table will be used at the next reboot. Syncing disks. C'est la nouvelle partition /dev/hda3 que nous utilisons pour créer un nouveau volume physique LVM. On visualise ensuite les propriétés des deux volumes physiques du système virtuel. # pvcreate /dev/hda3 Physical volume "/dev/hda3" successfully created vm:/home/etu# pvdisplay --- Physical volume --- PV Name /dev/hda2 VG Name vm-debian PV Size 3,76 GB / not usable 3,52 MB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 962 Free PE 0 Allocated PE 962 PV UUID ahs2DO-u8gV-VVnN-sUOT-dUwv-fjlz-VRQpUl "/dev/hda3" is a new physical volume of "7,44 GB" --- NEW Physical volume --- PV Name /dev/hda3 VG Name PV Size 7,44 GB Allocatable NO PE Size (KByte) 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID IHbF6G-Tfye-uUXC-mcWf-KUNd-MrSD-y4Yy4y On remarque facilement les différences entre les deux volumes physiques LVM. Le volume physique /dev/hda3 n'est associé à aucun groupe de volumes et ne dispose pas d'une taille de bloc ou Physical Extent (PE) définie. L'étape suivante consiste à étendre le groupe de volumes logiques avec le nouveau volume physique disponible ; c'est le rôle de la commande vgextend. On visualise ensuite le résultat sur les propriétés du nouveau volume physique. # vgextend vm-debian /dev/hda3 Volume group "vm-debian" successfully extended # pvdisplay /dev/hda3 --- Physical volume --- PV Name /dev/hda3 VG Name vm-debian PV Size 7,44 GB / not usable 773,50 KB Allocatable yes PE Size (KByte) 4096 Total PE 1904 Free PE 1904 Allocated PE 0 PV UUID IHbF6G-Tfye-uUXC-mcWf-KUNd-MrSD-y4Yy4y Pour achever l'opération, il est nécessaire d'affecter l'espace offert par le nouveau volume physique aux différents volumes logiques du système. Pour étendre les volumes logiques voulus à l'aide de la commande lvextend, on utilise deux options différentes : -L pour ajouter une capacité fixe et -l pour attribuer un pourcentage de volume. # lvextend -L +512M /dev/mapper/vm--debian-root Extending logical volume root to 1000,00 MB Logical volume root successfully resized # lvextend -L +2560M /dev/mapper/vm--debian-usr Extending logical volume usr to 4,36 GB Logical volume usr successfully resized # lvextend -L +2560M /dev/mapper/vm--debian-var Extending logical volume var to 3,09 GB Logical volume var successfully resized # lvextend -l +100%FREE /dev/mapper/vm--debian-home Extending logical volume home to 2,48 GB Logical volume home successfully resized Il ne reste plus qu'à répercuter l'extension des volumes logiques au niveau système de fichiers à l'aide de la commande resise2fs. # resize2fs /dev/mapper/vm--debian-root resize2fs 1.41.3 (12-Oct-2008) Le système de fichiers de /dev/mapper/vm--debian-root est monté sur / ; le changement de taille doit être effectué en ligne old desc_blocks = 2, new_desc_blocks = 4 En train d'effectuer un changement de taille en ligne de /dev/mapper/vm--debian-root vers 1024000 (1k) blocs. Le système de fichiers /dev/mapper/vm--debian-root a maintenant une taille de 1024000 blocs. # resize2fs /dev/mapper/vm--debian-usr resize2fs 1.41.3 (12-Oct-2008) Le système de fichiers de /dev/mapper/vm--debian-usr est monté sur /usr ; le changement de taille doit être effectué en ligne old desc_blocks = 1, new_desc_blocks = 1 En train d'effectuer un changement de taille en ligne de /dev/mapper/vm--debian-usr vers 1142784 (4k) blocs. Le système de fichiers /dev/mapper/vm--debian-usr a maintenant une taille de 1142784 blocs. # resize2fs /dev/mapper/vm--debian-var resize2fs 1.41.3 (12-Oct-2008) Le système de fichiers de /dev/mapper/vm--debian-var est monté sur /var ; le changement de taille doit être effectué en ligne old desc_blocks = 1, new_desc_blocks = 1 En train d'effectuer un changement de taille en ligne de /dev/mapper/vm--debian-var vers 793600 (4k) blocs. Le système de fichiers /dev/mapper/vm--debian-var a maintenant une taille de 793600 blocs. # resize2fs /dev/mapper/vm--debian-home resize2fs 1.41.3 (12-Oct-2008) Le système de fichiers de /dev/mapper/vm--debian-home est monté sur /home ; le changement de taille doit être effectué en ligne old desc_blocks = 2, new_desc_blocks = 10 En train d'effectuer un changement de taille en ligne de /dev/mapper/vm--debian-home vers 2596864 (1k) blocs. Le système de fichiers /dev/mapper/vm--debian-home a maintenant une taille de 2596864 blocs. En conclusion, on visualise l'espace occupé et disponible sur l'ensemble des volumes logiques du système virtuel. # df -h Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/mapper/vm--debian-root 969M 106M 814M 12% / tmpfs 503M 0 503M 0% /lib/init/rw udev 10M 152K 9,9M 2% /dev tmpfs 503M 0 503M 0% /dev/shm /dev/hda1 228M 20M 197M 9% /boot /dev/mapper/vm--debian-home 2,4G 14M 2,3G 1% /home /dev/mapper/vm--debian-usr 4,3G 1,2G 3,0G 29% /usr /dev/mapper/vm--debian-var 3,0G 236M 2,7G 9% /var Du point de vue du système hôte, rien n'a changé dans la mesure ou l'extension réalisée n'est pas occupée et que le format compressé qcow2 joue son rôle. $ ls -sh vm0-debian-testing-amd64-X11* 2,3G vm0-debian-testing-amd64-X11-extended.qcow2 2,3G vm0-debian-testing-amd64-X11.qcow2 Bien sûr, les valeurs numériques utilisées dans cette section ne sont que des exemples. Il est possible de faire beaucoup d'autres manipulations avec le gestionnaire de volume logique LVM. L'extension de capacité n'est qu'une facette des fonctionnalités offertes. Pour l'ensemble des opérations présentées dans cette section, on utilise indifféremment les solutions KVM (et|ou) QEMU. Les configurations réseaux sont valables dans les deux cas. Le mode utilisateur est la solution par défaut ; celle utilisée lors de la phase d'installation d'une nouvelle instance de machine virtuelle (Voir ). Il correspond à l'utilisation d'une pile de protocoles réseau dans l'espace mémoire utilisateur. L'avantage, c'est que cette configuration réseau automatisée ne nécessite aucune opération système avec les droits super utilisateur. L'inconvénient, c'est qu'aucune communication réseau de type service Internet depuis un hôte réel vers la machine virtuelle n'est possible. Il est cependant possible d'accéder à la «console» d'une machine virtuelle en mode utilisateur depuis le système hôte à l'aide de l'option redir. La documentation officielle se trouve à la page Using the user mode network stack Selon les termes de cette documentation, la machine virtuelle se comporte comme un hôte réseau situé derrière un pare-feu qui bloque les connexions entrantes. La topologie de la connexion et des services se présente sous la forme suivante : QEMU VLAN <------> Firewall/DHCP server <-----> Internet | (10.0.2.2) | ----> DNS server (10.0.2.3) | ----> SMB server (10.0.2.4) Ce mode de fonctionnement intégré à la solution de virtualisation reproduit les services traditionnellement offerts par un routeur domestique ADSL : traduction d'adresses IP (NAT), configuration réseau cliente dynamique (DHCP) et résolution des noms de domaines (DNS). Le serveur virtuel attribue dynamiquement les adresses IP à partir de 10.0.2.15 aux interfaces réseau de la machine virtuelle. On commence par lancer l'instance de machine virtuelle. $ qemu \ -name telnet-access-example \ -m $memory \ -rtc base=localtime,clock=host \ -drive file=vm0-debian-stable-x86.raw,if=virtio,media=disk,boot=on \ -k fr \ -usb -usbdevice tablet \ -redir tcp:5555::23 L'option -redir assure la redirection des connexions TCP sur le port 5555 du système hôte vers le port 23 de la machine virtuelle. Une fois la machine virtuelle lancée, on installe les paquets nécessaires et on configure le service telnet. Côté système hôte ou client telnet, on vérifie que le paquet telnet-ssl est bien installé. $ dpkg -l telnet-ssl |grep ^ii ii telnet-ssl 0.17.24+0.1-20 The telnet client with SSL encryption support Côté machine virtuelle ou serveur telnet, on vérifie que le paquet telnetd-ssl est bien installé. $ dpkg -l telnetd-ssl |grep ^ii ii telnetd-ssl 0.17.24+0.1-20 The telnet server with SSL encryption support Pour faire simple, on autorise toutes les connexions entrantes sur le service telnet et on vérifie que le service est ouvert. # echo "in.telnetd: ALL" >>/etc/hosts.allow # tcpdchk -v Using network configuration file: /etc/inetd.conf >>> Rule /etc/hosts.allow line 14: daemons: in.telnetd clients: ALL access: granted Il ne reste plus qu'à ouvrir une connexion telnet depuis le système hôte. :~$ telnet localhost 5555 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. Debian GNU/Linux lenny/sid vm0 login: etu Password: Last login: Wed May 14 17:00:13 CEST 2008 from 10.0.2.2 on pts/2 Linux vm0 2.6.24-1-686 #1 SMP Sat Apr 19 00:37:55 UTC 2008 i686 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. etu@vm0:~$ w 17:36:47 up 1:06, 2 users, load average: 0,04, 0,01, 0,00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT etu pts/1 10.0.2.2 17:36 0.00s 0.44s 0.06s w Du point de vue configuration réseau, l'interface Ethernet de la machine virtuelle a été configurée via le service DHCP intégré à l'émulateur. # lspci | grep -i ethernet 00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) # grep -i dhcp /var/log/syslog vm0 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 vm0 dhclient: DHCPOFFER from 10.0.2.2 vm0 dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 vm0 dhclient: DHCPACK from 10.0.2.2 vm0 dhclient: bound to 10.0.2.15 -- renewal in 40347 seconds. La configuration réseau obtenue est la suivante : # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 inet adr:10.0.2.15 Bcast:10.0.2.255 Masque:255.255.255.0 adr inet6: fe80::5054:ff:fe12:3456/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1879 errors:0 dropped:0 overruns:0 frame:0 TX packets:1502 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:1292554 (1.2 MiB) TX bytes:169257 (165.2 KiB) Interruption:10 Adresse de base:0xc100 vm0:/home/etu# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 eth0 Les informations relevées dans les copies d'écran ci-dessus montrent que ce sont les fonctions intégrées de l'émulateur qui ont servi à la configuration de l'interface réseau Ethernet de l'hôte virtuel. La solution retenue pour les communications réseau entre système hôte et machine virtuelle utilise la fonction TUN/TAP du noyau Linux. Cette solution est utilisée dans toutes les sections suivantes de ce document. Indépendamment du contexte de la virtualisation, TUN/TAP est une fonction de réception et de transmission de paquets entre le noyau et les programmes de l'espace utilisateur. Cette fonction peut être vue comme une simple interface point à point ou Ethernet qui, au lieu de recevoir les paquets d'un média physique, les reçoit du programme de l'espace utilisateur. De même, cette interface au lieu d'envoyer les paquets vers un média physique, les transmet au programme de l'espace utilisateur. Dans le contexte de ce document, le programme de l'espace mémoire utilisateur est l'instance virtuelle de système d'exploitation. L'interface réseau TUN/TAP devient un canal de communication réseau entre le système hôte et un système émulé via KVM (et|ou) QEMU. Cette section se décompose en trois parties consacrées à la mise en œuvre d'une interface TAP. La première propose une configuration d'interface à partir de la session utilisateur alors que la deuxième et la troisième proposent une configuration permanente au niveau système. Seule la troisième partie est spécifique à la distribution Debian GNU/Linux. À l'usage et compte tenu de la faible empreinte mémoire du module tun, la deuxième ou la troisième solution sont à privilégier. La création d'une interface TAP doit se faire par l'intermédiaire d'un programme de l'espace mémoire utilisateur. Il existe deux méthodes classiques de création d'interface à partir des outils fournis avec les paquets de la distribution Debian GNU/Linux. User-Mode Linux uml-utilities Ce paquet contient les programmes utilitaires liés à la solution User-Mode Linux qui permet «d'imbriquer» l'exécution de plusieurs noyaux Linux. L'utilitaire de manipulation des interfaces TUN/TAP est baptisé tunctl. Voici un exemple de séquence de configuration d'une interface TAP. # tunctl -d tap0 Set 'tap0' nonpersistent # tunctl -u etu -t tap0 Set 'tap0' persistent and owned by uid 1000 # ifconfig tap0 tap0 Link encap:Ethernet HWaddr 00:ff:3b:71:37:bb BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:500 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Comme la solution User-Mode Linux ne fait pas partie des outils utilisés dans le contexte de ce document, ce mode de configuration ne sera pas utilisé par la suite. OpenVPN openvpn OpenVPN est une solution très populaire de mise en œuvre de réseaux privés virtuels (VPN) ou tunnels IP utilisant les fonctions de chiffrement, de certification et d'authentification de la bibliothèque OpenSSL. La commande # openvpn --mktun --dev tap0 suffit à la création de l'interface TAP. Comme OpenVPN est utilisé par ailleurs dans l'infrastructure des travaux pratiques de la filière STRI, c'est cette solution qui est retenue pour la création des interfaces TAP. Les informations de la version utilisée pour les manipulations sont les suivantes : # dpkg -l openvpn |grep ^ii ii openvpn 2.1~rc15-1 virtual private network daemon # openvpn --mktun --dev tap0 Wed May 14 21:22:52 2008 TUN/TAP device tap0 opened Wed May 14 21:22:52 2008 Persist state set to: ON # ifconfig tap0 tap0 Link encap:Ethernet HWaddr 00:ff:11:82:55:fe BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Si on retient l'utilisation d'openvpn pour créer l'interface tap0, il est préférable d'utiliser un script qui permet aussi de configurer cette interface sur le système hôte. #!/bin/bash # $Id: tap-up.sh 1305 2008-06-08 20:59:09Z latu $ # Run this tap interface setup script before KVM/QEMU launch # Sudo should be configured with the two following tools allowed from user level # user ALL = NOPASSWD: /sbin/ifconfig, /usr/sbin/openvpn # These scripts should be located in ~/bin as they are run at normal user level if [ -z $1 ] || [ -z $2 ]; then echo "Usage: tap-up.sh {tap interface} {IP address}" exit 1 fi TAP=`/sbin/ifconfig 2>/dev/null|grep $1|cut -d " " -f 1` if [ "$TAP" != "$1" ]; then sudo /usr/sbin/openvpn --mktun --dev $1 >/dev/null 2>&1 fi sudo /sbin/ifconfig $1 $2 Dans cet exemple, l'exécution du script est indépendante du lancement de l'instance de machine virtuelle. Cette configuration autonome de l'interface TAP correspond au cas le plus général. Comme ce script est utilisé au niveau utilisateur normal, on suppose qu'il est stocké dans le répertoire ~/bin/. C'est habituellement dans ce répertoire que l'on retrouve l'ensemble des (programmes|scripts) exécutables propres au compte utilisateur. Pour généraliser l'utilisation d'une interface TAP, il est possible de la paramétrer directement au niveau système dans le fichier de configuration des interfaces réseau. Voici un extrait de fichier /etc/network/interfaces. # The tap network interface auto tap0 iface tap0 inet static address 192.0.2.1 netmask 255.255.255.224 network 192.0.2.0 broadcast 192.0.2.31 pre-up /usr/sbin/openvpn --mktun --dev tap0 post-up su phil -c "vde_switch -d -F --tap tap0 -s /tmp/vde.ctl -M /tmp/vde.mgmt" post-up iptables-restore </var/lib/iptables/active pre-down kill `ps -o pid -C vde_switch --no-headers` post-down /usr/sbin/openvpn --rmtun --dev tap0 La configuration de l'interface se présente avec les éléments classiques communs à n'importe quelle interface réseau IP statique configurée sur un système Debian GNU/Linux ou apparenté. On y trouve, l'adresse IP, le masque réseau, l'adresse du réseau ainsi que l'adresse de diffusion. La directive pre-up permet de lancer la commande de création de l'interface au niveau système avant l'application des paramètres de configuration IP. À ce niveau, l'appel à OpenVPN ne fait qu'installer le périphérique (device) tap0. On retrouve les traces de cette opération dans le journal de l'initialisation du système. $ egrep ' tap| tun' /var/log/kern.log tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> tap0: no IPv6 routers present tun0: Disabled Privacy Extensions La directive post-up permet de lancer la commande d'initialisation du commutateur virtuel VDE après la configuration de l'interface tap0. Comme pour l'interface réseau, l'empreinte mémoire du commutateur virtuel est suffisamment légère pour que l'on puisse rendre son chargement systématique sans pénaliser les performances du système hôte. De plus, cette interface tap0 constitue l'unique «lien montant» (uplink) du commutateur virtuel vers les autres réseaux. Il est donc logique d'associer le démarrage du commutateur à la configuration de l'interface. L'utilisation du commutateur virtuel VDE est détaillée dans la . Dans la configuration présentée ici, l'utilisateur phil est propriétaire du processus vde_switch et des sockets de communication. La seconde directive post-up permet d'installer les règles de filtrage réseau consécutives à l'activation de l'interface. L'objectif de ces règles de filtrage est de rendre l'utilisation du ou des réseau(x) virtuel(s) transparente vis-à-vis des réseaux réels situé «à l'extérieur» du système hôte. Il s'agit donc d'un cas classique de traduction d'adresse source sur les interfaces physiques de ce système hôte. Dans le cas de l'ordinateur «transportable» de l'enseignant, on peut trouver les règles suivantes. # cat /var/lib/iptables/active *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A POSTROUTING -p tcp -m tcp --syn -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu -A POSTROUTING -o wlan0 -j MASQUERADE -A POSTROUTING -o eth0 -j MASQUERADE COMMIT Même si l'opération n'est pas effectuée à ce niveau, on suppose que la fonction routage du noyau est activée pour les paquets IP puissent transiter entre l'interface tap0 et les autres interfaces réseau du système hôte. # sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1 Avec la directive pre-down, on aborde les opérations d'arrêt de l'interface tap0. Dans le cas présent, il s'agit d'arrêter le commutateur virtuel VDE en tuant le processus correspondant. Enfin, la commande appelée par la directive post-down efface le canal de communication entre l'interface réseau virtuelle dans l'espace mémoire utilisateur et le sous-système réseau du noyau. Cette opération est effectuée une fois que les paramètres de configuration IP ont été supprimés et que l'interface est inactive. Sur un système Debian GNU/Linux, il est possible configurer directement une interface TAP tout en initialisant le commutateur Virtual Distributed Ethernet. Cette méthode de configuration est très voisine de celle présentée dans la section ci-dessus. Elle ne se différencie que par l'utilisation des scripts fournis avec le paquet vde2. Si on reprend un extrait du fichier /etc/network/interfaces, on obtient la syntaxe suivante. auto tap0 iface tap0 inet static address 192.0.2.1 netmask 255.255.255.224 network 192.0.2.0 broadcast 192.0.2.31 vde2-switch - La dernière instruction : vde2-switch - déclenche l'initialisation du commutateur virtuel avec les attributs définis dans les scripts du paquet vde2. $ ps aux | grep vde /usr/bin/vde_switch -s /var/run/vde2/tap0.ctl \ -m 660 -g vde2-net \ -p /var/run/vde2/tap0.pid \ -t tap0 \ -M /var/run/vde2/tap0.mgmt --mgmtmode 660 \ -d L'ensemble des options de configuration du commutateur est présenté à la . On relève cependant les éléments relatifs au groupe propriétaire du processus et à son masque de permissions. Les canaux de communication avec le commutateur sont définis dans le répertoire /var/run/ comme pour n'importe quel autre service d'un système Debian GNU/Linux. Ici, le répertoire /var/run/vde2/ contient toutes les références de communication avec le processus vde_switch. $ ll /var/run/ | grep vde drwxrws--- 3 vde2-net vde2-net 4,0K jun 27 14:12 vde2 L'utilisteur système vde2-net et les membres du groupe du même nom ont accès au contenu de ce répertoire qui contient le répertoire des sockets de communication, l'identifiant de processus et le socket de gestion de la configuration du commutateur. Les valeurs numériques 660 correspondent au masque des permissions sur les objets du système de fichiers. Ces objets sont des sockets de type UNIX. La valeur numérique 660 correspond au masque rw-rw---- qui donne les droits de lecture et d'écriture exclusivement au propriétaire et au groupe. D'après les éléments identifiés ci-dessus, il est nécessaire que le compte utilisateur «normal» appartienne au groupe vde2-net pour utiliser le commutateur et l'interface tap0. Si on reprend l'exemple de la section précédente, c'est le compte utilisateur phil qui est concerné. $ grep vde /etc/group vde2-net:x:120:phil Les scripts proposés avec le paquet vde2 assurent la configuration de l'interface tap0 mais non son activation. De plus, il manque la partie filtrage relativement à la section précédente. On implante donc un script supplémentaire dans le répertoire /etc/network/if-up.d/ qui se charge de ces opérations. # cat /etc/network/if-up.d/tap0 #!/bin/sh if [ -d "/proc/sys/net/ipv4/conf/tap0" ] then /sbin/ifup tap0 fi if [ -f "/var/lib/iptables/active" ] then /sbin/iptables-restore </var/lib/iptables/active fi Une fois ce dernier script en place, on dispose d'une interface de communication fonctionnelle entre le système hôte et les instances de machines virtuelles. Relativement au contexte précédent, ce mode permet de faire «apparaître» une interface réseau de machine virtuelle sur le système hôte. Cette configuration nécessite donc l'utilisation de droits super utilisateur pour administrer les interfaces depuis le système hôte. Ces droits peuvent être délégués «à l'acte» via sudo ou utilisés directement à la console. Voici la topologie type des communications réseau entre une machine virtuelle, un système hôte et un hôte distant. Topologie réseau communication point à point Topologie réseau communication point à point - vue complète On trouve ci-dessous les attributions d'adresses IPv4 en fonction des types d'interfaces. Bien entendu, ces adresses ne sont que des exemples utiles à l'interprétation des étapes de mise en place de la topologie illustrée. Système Interface Adresse IPv4 hôte eth0 192.168.1.1/24 hôte tap0 192.0.2.1/24 virtuel eth0 192.0.2.2/24 distant eth0 192.168.1.7/24 Pour la suite, on considère que la configuration et le fonctionnement du réseau local de communication entre le système hôte et le système distant sont déjà validés. Configuration de l'interface TAP sur le système hôte. $ ./scripts/tap-up.sh tap0 192.0.2.1/24 $ /sbin/ifconfig tap0 tap0 Link encap:Ethernet HWaddr 00:ff:8c:db:de:99 inet adr:192.0.2.1 Bcast:192.0.2.255 Masque:255.255.255.0 adr inet6: fe80::2ff:8cff:fedb:de99/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:47 overruns:0 carrier:0 collisions:0 lg file transmission:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Lancement de l'instance de machine virtuelle sur le système hôte. $ kvm \ -name pointopoint-example \ -m 512 \ -rtc base=localtime,clock=host \ -drive file=vm0-debian-stable-x86_64.raw,if=virtio,media=disk,boot=on \ -k fr \ -usb -usbdevice tablet \ -net nic,vlan=0 \ -net tap,vlan=0,ifname=tap0,script=no L'option -net nic indique que la machine virtuelle doit disposer d'une interface réseau (nic : network interface card) émulée. Le paramètre vlan=0 désigne le réseau local virtuel (vlan : virtual local area network) auquel cette interface est raccordée. L'option -net tap,vlan=0,ifname=tap0 indique que l'interface TAP du système hôte doit être raccordée au même réseau local virtuel (vlan) que l'interface réseau émulée. L'option no indique que l'on ne fait appel à aucun script d'initialisation et de configuration d'interface TAP du système hôte lors du lancement de la machine virtuelle. Mise en place des entrées statiques de la table de routage du système distant pour pouvoir joindre la machine virtuelle via le système hôte. # route add -net 192.0.2.0 netmask 255.255.255.0 dev eth1 # route add -host 192.0.2.2 gw 192.0.2.1 # ping -c 2 192.0.2.2 PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data. 64 bytes from 192.0.2.2: icmp_seq=1 ttl=63 time=3.81 ms 64 bytes from 192.0.2.2: icmp_seq=2 ttl=63 time=1.78 ms --- 192.0.2.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1007ms rtt min/avg/max/mdev = 1.782/2.797/3.812/1.015 ms Test de connexion à la machine virtuelle. :~$ ssh etu@192.0.2.2 etu@192.0.2.2's password: Linux vm0 2.6.24-1-amd64 #1 SMP Fri Apr 18 23:08:22 UTC 2008 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed May 14 22:12:46 2008 from topaze.linux.home etu@vm0:~$ Par définition, l'utilisation d'un pont (bridge) permet d'étendre un réseau local. Dans le contexte de la virtualisation, les ponts sont couramment employé pour rendre les instances de machines virtuelles visibles depuis le réseau physique réel. La configuration la plus simple utilise un pont entre l'interface physique du système hôte et l'interface de l'instance de machine virtuelle. Topologie réseau commutation virtuelle Topologie réseau commutation virtuelle - vue complète Dans ce contexte, l'objectif est de faire communiquer les machines virtuelles entre elles. Pour ce faire, on utilise un commutateur virtuel lui aussi : Virtual Distributed Ethernet. Ce commutateur est un processus utilisateur appelé vde_switch. Il est fourni par le paquet vde2. Voici un exemple de topologie réseau utilisant vde_switch. Topologie réseau commutation virtuelle Topologie réseau commutation virtuelle - vue complète C'est cette topologie de base que j'utilise systématiquement pour les travaux pratiques de la série Administration système en réseau. En effet, on retrouve une machine virtuelle de type serveur et une autre de type client. Le système hôte joue le rôle de passerelle donnant accès à l'Internet (et|ou) à un système distant. On trouve ci-dessous les attributions d'adresses IPv4 en fonction des types d'interfaces. Bien entendu, ces adresses ne sont que des exemples utiles à l'interprétation des étapes de mise en place de la topologie illustrée. Système Interface Adresse IPv4 hôte eth0 192.168.1.1/24 hôte tap0 192.0.2.1/24 machine virtuelle «serveur» eth0 192.0.2.2/24 machine virtuelle «client» eth0 192.0.2.3/24 distant eth0 192.168.1.7/24 Cette section reprend la configuration manuelle de l'interface TAP (Voir ) à partir d'un compte utilisateur normal et décrit son «brassage» sur le commutateur virtuel. La configuration du commutateur Virtual Distributed Ethernet est elle aussi réalisée avec les droits du compte utilisateur normal. Interface TAP La configuration de l'interface TAP sur le système hôte reprend les éléments présentés précédemment . $ ./scripts/tap-up.sh tap0 192.0.2.1/24 $ /sbin/ifconfig tap0 tap0 Link encap:Ethernet HWaddr 00:ff:8c:db:de:99 inet adr:192.0.2.1 Bcast:192.0.2.255 Masque:255.255.255.0 adr inet6: fe80::2ff:8cff:fedb:de99/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:47 overruns:0 carrier:0 collisions:0 lg file transmission:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Table de routage et traduction d'adresses (NAT) L'objectif principal des opérations présentées ici est de «préserver» la table de routage du système hôte. En effet, ce système correspond le plus souvent à un ordinateur portable utilisé pour les enseignements. La connexion au réseau public de ce portable peut utiliser plusieurs types d'interfaces différentes : Ethernet filaire, Wifi (et|ou) VPN. Il faut donc que les instances de machines virtuelles puissent avoir accès aux réseaux réels externes via n'importe laquelle de ces différentes interfaces. On commence donc par activer le routage des paquets IPv4 au niveau du noyau Linux manuellement ou au niveau système dans le fichier de configuration de sysctl. # echo 1 >/proc/sys/net/ipv4/ip_forward # grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward=1 Ensuite, on utilise les fonctions de traduction d'adresses IP sources (S-NAT) dynamiques du noyau Linux à l'aide de l'outil de configuration ipatbles. # iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -j MASQUERADE La cible MASQUERADE permet l'utilisation dynamique de n'importe quelle interface de sortie du système hôte vers le réseau public. La traduction d'adresses se fait sur la base des adresses IP sources du réseau des instances de machines virtuelles desservi par le commutateur vde_switch. Ces adresses sources sont désignées à l'aide de l'option -s 192.0.2.0/24. On valide le fonctionnement de la traduction d'adresses en consultant l'état des chaînes correspondantes. # iptables -vL -t nat Chain PREROUTING (policy ACCEPT 56 packets, 4650 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 220 packets, 20710 bytes) pkts bytes target prot opt in out source destination 32 1966 MASQUERADE all -- any any 192.0.2.0/24 anywhere Chain OUTPUT (policy ACCEPT 220 packets, 20710 bytes) pkts bytes target prot opt in out source destination Il est aussi possible, avec des outils comme iptsate, de visualiser en temps réel l'état des tables de suivi de communication du système de filtrage netfilter/iptables. Commutateur virtuel Virtual Distributed Ethernet Le commutateur virtuel vde_switch doit être lancé avant les instances de machines virtuelles pour que le brassage des connexions puisse se faire. Voici un exemple de commande de lancement du commutateur suivi de la visualisation du socket et du processus correspondant. $ vde_switch -d --tap tap0 -s /tmp/vde.ctl -M /tmp/vde.mgmt $ ls -lAh /tmp/vde* srw------- 1 phil phil 0 jun 1 17:29 /tmp/vde.mgmt /tmp/vde.ctl: total 0 srwx------ 1 phil phil 0 jun 1 17:29 ctl $ pgrep -l -u phil vde 11198 vde_switch Avec l'option --tap, le commutateur virtuel est «connecté» au système hôte via une interface TAP comme dans le cas des communications point à point. Cette connexion correspond au lien vers le réseau externe «réel» : le réseau local du système hôte et l'Internet. Le réseau local auquel appartient cette interface TAP apparaît dans la table de routage du système hôte. # route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1 L'option -s désigne le socket de communication sur lequel les machines virtuelles vont se brancher. Ce socket sert au brassage des connexions de toutes les machines virtuelles. L'option -M désigne le socket de gestion de la configuration du commutateur virtuel. Ces opérations se font via ce socket dédié. Le paquet vde2 fournit un programme utilisateur pour l'utiliser : vdeterm. On observe que l'utilisateur normal phil est propriétaire des sockets de communication et de gestion du commutateur. Comme les machines virtuelles sont elles même des processus utilisateur, il est nécessaire que ces processus aient la même identité (uid) que le socket. Il est possible de combiner le script d'initialisation de l'interface TAP (voir ) et le lancement du commutateur virtuel à l'aide du script suivant : #!/bin/bash # $Id: vde-up.sh 1305 2008-06-08 20:59:09Z latu $ # Run this virtual ethernet switch setup script before KVM/QEMU launch # These scripts should be located in ~/bin as they are run at normal user level if [ -z $1 ] || [ -z $2 ]; then echo "Usage: vde-up.sh {tap interface} {IP address}" exit 1 fi ~/bin/tap-up.sh $1 $2 vde_switch -d --tap $1 -s /tmp/vde.ctl -M /tmp/vde.mgmt Avec cette combinaison de scripts, la séquence d'initialisation de l'interface TAP et du commutateur virtuel associé devient : $ vde-up.sh tap0 192.0.2.1/2 Instances de machines virtuelles Le lancement des machines virtuelles sur le système hôte se fait en fonction du brassage à réaliser. Il faut désigner le socket de communication avec le commutateur virtuel et l'interface de réseau local utilisée par la machine virtuelle. $ qemu \ -drive file=vm0-debian-i386.raw,if=virtio,media=disk,boot=on \ -m 128 \ -net vde,sock=/tmp/vde.ctl \ -net nic,vlan=0,macaddr=52:54:00:12:34:62 & $ qemu \ -drive file=vm1-debian-i386.raw,if=virtio,media=disk,boot=on \ -m 128 \ -net vde,sock=/tmp/vde.ctl \ -net nic,vlan=0,macaddr=52:54:00:12:34:63 & Quelle que soit l'instance de machine virtuelle initialisée, on utilise le socket unique de communication avec le commutateur virtuel. Dans cet exemple, le brassage des ports du commutateur virtuel se fait dynamiquement dans l'ordre des connexions libres. Les informations de brassage sont visualisées dans la et les deux instances lancées occupent les ports numérotés 002 et 003. Ces informations se retrouvent aussi au niveau de l'arborescence des sockets utilisateur. $ ls -lAh /tmp/vde* srwx------ 1 phil phil 0 jun 1 17:53 /tmp/vde.ctl.19747-00000 srwx------ 1 phil phil 0 jun 1 18:03 /tmp/vde.ctl.21781-00000 srw------- 1 phil phil 0 jun 1 17:29 /tmp/vde.mgmt /tmp/vde.ctl: total 0 srwx------ 1 phil phil 0 jun 1 17:53 002 srwx------ 1 phil phil 0 jun 1 18:03 003 srwx------ 1 phil phil 0 jun 1 17:29 ctl Dans l'exemple ci-dessus, les valeurs 19747 et 21781 correspondent aux numéros des deux processus de machine virtuelle sur le système hôte. Si les interfaces Ethernet des machines virtuelles sont configurées au niveau du système d'exploitation invité, il est malgré tout nécessaire de préciser le paramétrage matériel de ces interfaces au lancement d'une instance. En effet, l'adresse physique MAC d'une machine virtuelle est toujours la même par défaut. C'est la raison pour laquelle chaque machine virtuelle est lancée avec une adresse MAC distincte. Il faut se rappeler que la commutation Ethernet réelle ou virtuelle est basée sur la constitution d'une table de correspondance entre adresses MAC et numéro de port. L'état de cette table de correspondance est disponible via l'interface de gestion du commutateur vde_switch. Voir . De plus, il est possible d'utiliser des réseaux locaux virtuels (VLANs) en constituant des groupes logiques de ports de commutateur. Ici, les deux instances de machines virtuelles appartiennent au même groupe logique : le VLAN numéro 0. Configuration du commutateur virtuel La visualisation et la gestion de la configuration du commutateur virtuel sur le système hôte se fait à l'aide d'un socket dédié présenté lors du lancement du processus vde_switch (Voir ). On accède à l'interface de gestion du commutateur virtuel via vdeterm, un outil fourni avec le paquet vde2. Le jeu des commandes disponibles sur la configuration du commutateur est disponible à partir de la commande help. Voici quelques exemples basiques de commandes de visualisation de l'état des connexions. $ vdeterm /tmp/vde.mgmt VDE switch V.2.2.0-pre2 (C) Virtual Square Team (coord. R. Davoli) 2005,2006,2007 - GPLv2 vde$ showinfo 0000 DATA END WITH '.' VDE switch V.2.2.0-pre2 (C) Virtual Square Team (coord. R. Davoli) 2005,2006,2007 - GPLv2 pid 14433 MAC 00:ff:c6:46:c5:14 uptime 2079 mgmt /tmp/vde.mgmt perm 0600 unsent_pktq_len 0 . 1000 Success vde$ port/allprint 0000 DATA END WITH '.' Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable IN: pkts 2218 bytes 2966493 OUT: pkts 1480 bytes 106042 -- endpoint ID 0008 module tuntap : tap0 Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable IN: pkts 1518 bytes 109167 OUT: pkts 2292 bytes 2972334 -- endpoint ID 0009 module unix prog : vdeqemu user=phil PID=19747\ SOCK=/tmp/vde.ctl.19747-00000 Port 0003 untagged_vlan=0000 ACTIVE - Unnamed Allocatable IN: pkts 73 bytes 5788 OUT: pkts 48 bytes 3893 -- endpoint ID 0011 module unix prog : vdeqemu user=phil PID=21781\ SOCK=/tmp/vde.ctl.21781-00000 . 1000 Success vde$ hash/print 0000 DATA END WITH '.' Hash: 0048 Addr: 52:54:00:12:34:63 VLAN 0000 to port: 003 age 1 secs Hash: 0088 Addr: 52:54:00:12:34:62 VLAN 0000 to port: 002 age 1 secs . 1000 Success La commande showinfo donne les paramètres du socket de gestion dédié et l'adresse MAC interne du commutateur. La commande port/allprint donne la liste des ports actifs du commutateur ainsi que les paramètres associés : numéro de port et de VLAN, interface ou socket associé au port, référence du processus utilisateur de machine virtuelle. La commande hash/print affiche la table de correspondance entre les adresses MAC et les numéros de ports actifs. Tout comme dans une commutateur réel, cette table est rafraîchie dynamiquement en fonction du trafic qui transite sur un port. On retrouve ici les deux adresses MAC données lors du lancement des instances de machines virtuelles . Cette section reprend les mêmes étapes que la précédente, en utilisant cette fois ci les paramètres de configuration fournis avec les paquets de la distribution Debian GNU/Linux. Interface TAP La configuration système de l'interface TAP sur la machine hôte reprend les éléments présentés précédemment dans la . auto tap0 iface tap0 inet static address 192.0.2.1 netmask 255.255.255.0 network 192.0.2.0 broadcast 192.0.2.255 vde2-switch - Table de routage et traduction d'adresses (NAT) Pour activer systématiquement la fonction de routage des paquets IP dans le noyau Linux, on utilise le fichier de configuration /etc/sysctl.conf dans lequel on donne la valeur 1 à la variable net.ipv4.ip_forward. # grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward=1 Pour appliquer les règles de filtrage et de traduction d'adresses sources, il est possible de créer un script exécuté lors de l'initialisation des interfaces réseau du système. Ce script est placé dans le répertoire /etc/network/if-up.d/. Voici un exemple. # cat /etc/network/if-up.d/iptables #!/bin/sh set -e daemon="/sbin/iptables" name="iptables" save="/sbin/iptables-save" restore="/sbin/iptables-restore" active="/var/lib/iptables/active" test -x "$daemon" -a -x "$save" -a -x "$restore" || exit 0 # Load iptables rules test -f $active || exit 0 echo -n "Starting $name: " $restore < "$active" echo "loaded active state" D'après ce script, les règles doivent êtres placées dans le fichier /var/lib/iptables/active. En sauvegardant le résultat de la commande iptables-save dans ce fichier, on obtient un jeu de règles du type suivant : # cat /var/lib/iptables/active *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A POSTROUTING -p tcp -m tcp --syn -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu -A POSTROUTING -o wlan0 -j MASQUERADE -A POSTROUTING -o eth0 -j MASQUERADE COMMIT Bien sûr, ces règles ne répondent qu'au contexte étudié. Elles n'ont aucune valeur en dehors de ce même contexte. Commutateur virtuel Virtual Distributed Ethernet Ici, le commutateur virtuel vde_switch est lancé automatiquement lors de l'initialisation de l'interface TAP. Le paramétrage est imposé comme indiqué dans la . Relativement à la section précédente sur la configuration manuelle, on remarque que l'accès au commutateur virtuel est réservé aux membres du groupe vde2-net. $ ls -lAh /var/run/vde2/* srw-rw---- 1 root vde2-net 0 sep 3 06:40 /var/run/vde2/tap0.mgmt -rw-r--r-- 1 root vde2-net 5 sep 3 06:40 /var/run/vde2/tap0.pid /var/run/vde2/tap0.ctl: total 0 srw-rw---- 1 root vde2-net 0 sep 3 06:40 ctl Instances de machines virtuelles Le lancement des machines virtuelles suit le même principe que précédemment. Il faut cependant adapter les références du «brassage» des connexions virtuelles aux nouvelles références de sockets. Le chemin utilisé est correspond à la copie d'écran ci-dessus : /var/run/vde2/tap0.ctl. Pour automatiser le lancement d'une instance de machine virtuelle on peut utiliser le script suivant. Les deux paramètres à fournir lorsque l'on utilise ce script sont le nom de l'image et le numéro du port du commutateur utilisé. Si le numéro de port n'est pas donné, le port 2 est utilisé par défaut. #!/bin/bash # $Id: startup.sh 1614 2011-03-17 22:41:04Z latu $ #RedOnBlack='\E[31;40m' RedOnBlack='\E[31m' vm=$1 shift memory=$1 shift port=$1 shift if [[ -z "$vm" || -z "$memory" || -z "$port" ]] then echo "ERREUR : paramètre manquant" echo "Utilisation : $0 <fichier image> <quantité mémoire en Mo> <port commutateur [2..32]>" exit 1 fi if (( $memory < 128 )) then echo "ERREUR : quantité de mémoire RAM insuffisante" echo "La quantité de mémoire en Mo doit être supérieure ou égale à 128" exit 1 fi macaddress="52:54:00:12:34:$port" echo -e "$RedOnBlack" echo "~> Machine virtuelle : $vm" echo "~> Mémoire RAM : $memory" echo "~> Port commutateur : $port" echo "~> Adresse MAC : $macaddress" tput sgr0 # -vga vmware \ kvm \ -daemonize \ -name $vm \ -m $memory \ -rtc base=localtime,clock=host \ -drive file=$vm,if=virtio,media=disk,boot=on \ -k fr \ -usb -usbdevice tablet \ -soundhw es1370 \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl,port=$port \ -net nic,vlan=1,model=virtio,macaddr=$macaddress \ $* Configuration du commutateur virtuel La visualisation et la gestion de la configuration du commutateur virtuel sur le système hôte se fait à l'aide d'un socket dédié affecté à l'aide de l'option -M lors du lancement du processus vde_switch. Cette affectation se fait via un script fourni avec le paquet vde2 : /etc/network/if-pre-up.d/vde2. Voici un exemple d'utilisation de l'interface de gestion et de configuration du commutateur virtuel basé sur l'utilisation de trois instances de machines virtuelles dont les interfaces réseau sont «brassées» sur des VLANs différents. On commence par créer un fichier image «différentiel» pour chaque instance à partir du fichier image maître choisi. $ ./scripts/diff-img.sh vm0-debian-stable-amd64-base.raw r1.raw $ ./scripts/diff-img.sh vm0-debian-stable-amd64-base.raw r2.raw $ ./scripts/diff-img.sh vm0-debian-stable-amd64-base.raw r3.raw On procède au lancement de chaque instance en affectant un numéro de port différent sur le commutateur virtuel. $ ./scripts/startup.sh r1.raw 512 2 $ ./scripts/startup.sh r2.raw 512 3 $ ./scripts/startup.sh r3.raw 512 4 Une fois les instances actives et après avoir validé les communications au niveau réseau à l'aide de la commande ping, on peut visualiser le résultats sur l'interface du commutateur. L'équivalent de la Table CAM du commutateur virtuel est donné par la commande hash/print. $ vdeterm /var/run/vde2/tap0.mgmt VDE switch V.2.2.3 (C) Virtual Square Team (coord. R. Davoli) 2005,2006,2007 - GPLv2 vde$ hash/print 0000 DATA END WITH '.' Hash: 0010 Addr: 52:54:00:12:34:02 VLAN 0000 to port: 002 age 21 secs Hash: 0016 Addr: ca:d9:0c:3a:a2:f1 VLAN 0000 to port: 001 age 21 secs Hash: 0034 Addr: 52:54:00:12:34:04 VLAN 0000 to port: 004 age 13 secs Hash: 0094 Addr: 52:54:00:12:34:03 VLAN 0000 to port: 003 age 13 secs . 1000 Success Dans la copie d'écran ci-dessus, on retrouve les valeurs choisies pour distinguer les adresses MAC et les numéros de ports. Pour obtenir des informations détaillées sur la correspondance entre les ports de commutation et les sockets de communication des instances de systèmes d'exploitation, on utilise la commande port/print. vde$ port/print 0000 DATA END WITH '.' Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: NONE Access Control: (User: NONE - Group: NONE) IN: pkts 353870 bytes 507588924 OUT: pkts 178720 bytes 13090480 -- endpoint ID 0006 module tuntap : tap0 Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: phil Access Control: (User: NONE - Group: NONE) IN: pkts 140180 bytes 10268912 OUT: pkts 274615 bytes 397341431 -- endpoint ID 0003 module unix prog : QEMU user=phil PID=31442 SOCK=/var/run/vde2/tap0.ctl/.31442-00000 Port 0003 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: phil Access Control: (User: NONE - Group: NONE) IN: pkts 38235 bytes 2765961 OUT: pkts 76949 bytes 109875833 -- endpoint ID 0008 module unix prog : QEMU user=phil PID=31452 SOCK=/var/run/vde2/tap0.ctl/.31452-00000 Port 0004 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: phil Access Control: (User: NONE - Group: NONE) IN: pkts 70 bytes 13110 OUT: pkts 144 bytes 20998 -- endpoint ID 0010 module unix prog : QEMU user=phil PID=31459 SOCK=/var/run/vde2/tap0.ctl/.31459-00000 . 1000 Success La copie d'écran ci-dessus illustre bien la correspondance entre les ports de commutation, l'interface TAP et les processus correspondant à chaque instance de système virtualisé. On retrouve les éléments introduits dans la . En reprenant l'identifiant de processus 31442 donné ci-dessus, on retrouve les références du système virtualisé dans la liste des processus du système hôte. $ ps aux | grep 31442 | grep -v grep phil 31442 4.2 1.0 685260 85100 pts/3 Sl 22:41 1:23 \ kvm -name r1.raw -m 512 -drive file=r1.raw,if=virtio,media=disk,boot=on \ -k fr -usb -usbdevice tablet -rtc base=localtime,clock=host \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl,port=2 \ -net nic,vlan=1,model=virtio,macaddr=52:54:00:12:34:2 Cet article sur l'utilisation des machines virtuelles dans le contexte de l'enseignement est loin de couvrir tous les aspects exploitation. De plus, les modalités d'interconnexion des machines virtuelles restent à étudier de façon plus approfondies. De quoi rédiger d'autres articles ! Voici un rappel des codes des différents scripts utilisés dans cet article. On commence par le plus important : le script startup.sh qui sert à lancer une instance de système virtualisé avec une configuration réseau prédéfinie. L'utilisation de ce script suppose que l'on utilise le commutateur vde sur lequel le port 1 est dédié à la communication avec le système hôte via l'interface tap0. Le script demande deux paramètres : la quantité de mémoire RAM allouée au système virtuel et le numéro de port du commutateur vde sur lequel ce système doit être connecté. Pour faciliter l'analyse de la configuration des connexions réseau, l'adresse MAC du système virtuel est composée en utilisant le numéro de port comme octet le plus à droite. #!/bin/bash # $Id: startup.sh 1614 2011-03-17 22:41:04Z latu $ #RedOnBlack='\E[31;40m' RedOnBlack='\E[31m' vm=$1 shift memory=$1 shift port=$1 shift if [[ -z "$vm" || -z "$memory" || -z "$port" ]] then echo "ERREUR : paramètre manquant" echo "Utilisation : $0 <fichier image> <quantité mémoire en Mo> <port commutateur [2..32]>" exit 1 fi if (( $memory < 128 )) then echo "ERREUR : quantité de mémoire RAM insuffisante" echo "La quantité de mémoire en Mo doit être supérieure ou égale à 128" exit 1 fi macaddress="52:54:00:12:34:$port" echo -e "$RedOnBlack" echo "~> Machine virtuelle : $vm" echo "~> Mémoire RAM : $memory" echo "~> Port commutateur : $port" echo "~> Adresse MAC : $macaddress" tput sgr0 # -vga vmware \ kvm \ -daemonize \ -name $vm \ -m $memory \ -rtc base=localtime,clock=host \ -drive file=$vm,if=virtio,media=disk,boot=on \ -k fr \ -usb -usbdevice tablet \ -soundhw es1370 \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl,port=$port \ -net nic,vlan=1,model=virtio,macaddr=$macaddress \ $* Le script ci-dessous, baptisé tap-up.sh, illustre la création manuelle d'une interface de type tap. Il n'est utile que dans le cas où la distribution ne propose pas de configuration intégrée. La présente le fichier de configuration à privilégier. #!/bin/bash # $Id: tap-up.sh 1305 2008-06-08 20:59:09Z latu $ # Run this tap interface setup script before KVM/QEMU launch # Sudo should be configured with the two following tools allowed from user level # user ALL = NOPASSWD: /sbin/ifconfig, /usr/sbin/openvpn # These scripts should be located in ~/bin as they are run at normal user level if [ -z $1 ] || [ -z $2 ]; then echo "Usage: tap-up.sh {tap interface} {IP address}" exit 1 fi TAP=`/sbin/ifconfig 2>/dev/null|grep $1|cut -d " " -f 1` if [ "$TAP" != "$1" ]; then sudo /usr/sbin/openvpn --mktun --dev $1 >/dev/null 2>&1 fi sudo /sbin/ifconfig $1 $2 Comme dans le cas précédent, la configuration manuelle du commutateur vde n'a de sens que si la distribution ne propose pas de configuration intégrée. Au script vde-up.sh ci-dessous, on doit préférer la syntaxe proposée dans la qui est beaucoup plus simple. #!/bin/bash # $Id: vde-up.sh 1305 2008-06-08 20:59:09Z latu $ # Run this virtual ethernet switch setup script before KVM/QEMU launch # These scripts should be located in ~/bin as they are run at normal user level if [ -z $1 ] || [ -z $2 ]; then echo "Usage: vde-up.sh {tap interface} {IP address}" exit 1 fi ~/bin/tap-up.sh $1 $2 vde_switch -d --tap $1 -s /tmp/vde.ctl -M /tmp/vde.mgmt